sloanelybutsurely / typeid-elixir Goto Github PK

when using a belongs_to field users must use define_type: false and specify a separate _id field with the appropriate prefix.

https://danschultzer.com/posts/prefixed-base62-uuidv7-object-ids-with-ecto has an example of using schema introspection to infer the prefix. we should do this.

maybe also add application config for default type values if a project uses exclusively :string or :binary_id

Ecto.ParameterizedType for TypeIDs

• :uuid/:binary_id or :string primitive type
• prefix: option
• module defined lazily
• test suite with test ecto repo

publish to hex on new release / tag

• CONTRIBUTING
• CODE_OF_CONDUCT

Uniq is great but including the entire dependency probably isn't necessary for our purposes. This package should instead include only what's required to parse out and generate v7 UUIDs.

The start of a basic UUID v7 generator already exists in this package: lib/type_id/uuid.ex.

Functions for converting to and from raw binary and string representations of UUIDs are missing

Include CHANGELOG

Automated?

• credo
• sobelow

I just published a working version of typeid: https://hex.pm/packages/typeid

Maybe we should join forces?

The TypeID structs aren't very portable in practice. Implementing protocols only goes so far.

Structs are particularly challenging when attempting to pattern match on things that are always strings like pubsub topics

Hello, thank you very much for making this library!

I'm having an issue where it appears when I insert new rows into my database they are randomly sorted instead of utilizing the current time. I've got my schema set up with:

@primary_key {:id, TypeID, autogenerate: true, prefix: "client", type: :binary_id}
@foreign_key_type TypeID

As a test run, I created 6 new clients with a few seconds between each and the resulting primary keys (in order of generation) were:
 

Autogenerated

client_2781hb3ysx8vkbvyjqva8jn8sf
client_6t2xhfj1bs847v0hj0xvt0zy0j
client_23tv3vfh1288k8cmjbmcj6sy3j
client_5qdn2175ga8zxt8fmhwacg7ksp
client_0h8yfhspdm9rgskv9y710rs9rz
client_56wqn921mw8z68qed0aa2pcqa4

When selecting the entries from this table ordered by the id, they do not return in the correct order and start with extremely dissimilar beginnings.

Manually generated

In iex if I use TypeID.new("client") the generated ids appear more immediately sensible and are correctly sorted so something seems amiss when I allow Ecto to autogenerate them.

iex(80)> TypeID.new("client") #repeat this for each line below
#TypeID<"client_01hwyg46cye1m8bp9c0bbyqgjb">
#TypeID<"client_01hwyg47dnevbrd93ypamb9tkf">
#TypeID<"client_01hwyg48zcegctnk497zkgm2bd">
#TypeID<"client_01hwyg4awqesdbp6t5c2agzg51">
#TypeID<"client_01hwyg4cxdfhv91crqy04aemnb">

I'm using:
ecto 3.11.2
ecto_psql_extras 0.7.15
ecto_sql 3.11.1
typeid_elixir 0.6.0
phoenix 1.7.12
phoenix_ecto 4.5.1
postgrex 0.17.5
with Elixir 1.16.2 (compiled with Erlang/OTP 26)

Thanks again, let me know if you need any additional information!

The typeid spec has been updated: jetify-com/opensource#306

jetify-com/typeid#7

TypeID should implement the String.Chars and Phoenix.HTML.Safe protocols so they are properly converted when interpolated in strings and templates.

:phoenix should be marked as an optional dependency and Phoenix.HTML.Safe should only be implemented if the module exists.

Resources

• String.Chars
• impl Inspect
• to_string/1
• Phoenix.HTML.Safe

• crockford base32 encode / decode
• others?

Determine a baseline and expand the testing matrix