Confusion on many_to_many (uuid::bytea coercion) about uniq

[bitwalker]

@ryanwinchester @cospin I've pushed a patch to main which allows you to specify a type: :uuid | :binary | :string value when defining the @primary_key attribute, e.g. @primary_key {:id, Uniq.UUID, version: 7, autogenerate: true, type: :uuid}.

Can one of you test whether or not that actually works? My suspicion is that the database might validate the UUID metadata (i.e. what version of UUID it is), but if not, then that makes for an easy fix.

I believe I chose to default to :binary for perf reasons, since it avoids the unnecessary encoding/decoding step, and is also how you benefit from the lexicographical ordering characteristics (IIRC); but I might make the default type :uuid rather than :string when :dump is not :raw, since that likely aligns better with how the data is stored in that case.

[cospin]

I just ran into the same problem.

[ryanwinchester]

I've worked around it for now by doing this, unfortunately.

  schema "users" do
    # ...
    # many_to_many :locations, Location, join_through: "user_locations"
    has_many :user_locations, UserLocation
    has_many :locations, through: [:user_locations, :location]
  end

[bitwalker]

I believe the issue is that the Ecto.ParameterizedType implementation defaults to a type of :binary, whereas the underlying column type is uuid, hence the cast to bytea in the query. Right now there isn't a way to override that to be :uuid, but that's easy enough to add, since we already support switching between :binary and :string depending on the UUID representation chosen, by providing the :dump option with a format other than :raw.

Unfortunately there isn't a way (AFAIK) to automatically set the type based on the underlying schema, and furthermore, I'm not sure if there is any validation done by the database on UUID values to ensure they are of a specific version/format, if so, we'd have to restrict which types of UUID formats can be used with the :uuid type. The built-in Ecto.UUID type for example, only supports generating v4 UUIDs.

In the near term, I'm tempted to just allow overriding the type returned by type/1 with :uuid, but I'd like to be smarter about it if possible.

[cospin]

I just tested with main and it works without issues now! Thank you!

[ryanwinchester]

@bitwalker also tested main on my use-case and it works now 🙏 👍

[ryanwinchester]

believe I chose to default to :binary for perf reasons, since it avoids the unnecessary encoding/decoding step, and is also how you benefit from the lexicographical ordering characteristics (IIRC);

If I recall correctly, I think it was a concern for mysql where :binary was the preferred way to store UUIDs (not sure if MySQL has improved now for UUIDs or not, I haven't used it in quite a while).

uuid column in postgres can be any type of UUID/version, but must be a valid UUID syntax. And yeah, as far as I know, it doesn't validate the version but I might be wrong (but doesn't generally matter for my purposes). Also UUID v6/v7 are ordered as expected.

[ryanwinchester]

Fixed in 3df2ec0