sevenshores/elixir-uuid-utils

UUID generators and utilities. Drop-in replacement for elixir_uuid.

elixir-uuid-utils's Issues

Ecto integration

Would be nice to provide an Ecto Type (or even a Type per UUID version?)

Request for UUID V7 Implementation

Hi Seven Shores Team,

I was searching for Unique Id generator and came across several Implementations:

---

• Default UUID package - Unmaintained.

• ULID - Pretty url, sortable, binary. but has milisecond granularity.

• ExKsuid - Pretty url, sortable, binary, but with 1 second granularity.

• NanoId - Random, pretty, custom alphabets, great for slugs sharing but uses string and is not-sortable.

• Finally: Elixir UUID Utils - with UUID V6 - Standard, sortable, with nano second granularity for great index locality!

---

Implementations SHOULD utilize UUID7 over UUID version 1 and 6 if possible. - IETF

---

Now, I am torn between ULID, KSUID & UUID V6 / V7.

Will V7 be implemented? (because I think it would be great as it will be based on a standard supported by many and also nanosecond granularity rocks)

Request takeover of hex package name

Hey @ryanwinchester. After digging through everything in elixir_uuid about trying to get updates done and getting no response, I saw that you forked and published this other package. Given the number of libraries that depend on elixir_uuid, I recommend attempting to take over the package on hex. It's a fairly straightforward process and I expect Hex would agree with the transfer request as this situation could certainly be construed as an abandoned package at this point.

https://hex.pm/policies/dispute

Improving mac_address node speed for UUID v1 (and v6)

There are ways to improve this.

See: zyro/elixir-uuid#45 and zyro/elixir-uuid#40

I would prefer a way to make it an opt-in feature either at run-time or compile time, though.
For example, if your application does not use UUID v1 or UUID v6 with mac_address type, then you don't need a GenServer updating a cache that you'll never use.

@whatyouhide are you still interested? Especially since this is just a fork of https://github.com/zyro/elixir-uuid

Issues with parameterized types

I've had issues using Ecto parameterized types.

I've removed them from the readme for now. [96d4bb4]

Will add more details and work on a solution some time in the future.

Add more tests

I'd like complete code coverage (I've been improving it), but also just some good tests would be nice.

Add a format option to UUID.valid?

As suggested in zyro/elixir-uuid#29 we could add another function head pattern matching for the format.

Autogenerating primary key IDs in Ecto creating v4 UUIDs when I define v6

  1) test Repo autogenerates proper UUID (UUID.Ecto.TypeTest)
     test/uuid/ecto/type_test.exs:162
     ** (Ecto.ChangeError) value `"1eb13723-da2d-6cc6-87fc-116a4aa5c86d"` for `UUID.TestSchema.foo_bar_id`
 in `insert` does not match type UUID.TestUUID6
     code: |> UUID.TestRepo.insert()
     stacktrace:
       (ecto 3.5.2) lib/ecto/repo/schema.ex:889: Ecto.Repo.Schema.dump_field!/6
       (ecto 3.5.2) lib/ecto/repo/schema.ex:898: anonymous fn/6 in Ecto.Repo.Schema.dump_fields!/5
       (stdlib 3.13) maps.erl:233: :maps.fold_1/3
       (ecto 3.5.2) lib/ecto/repo/schema.ex:896: Ecto.Repo.Schema.dump_fields!/5
       (ecto 3.5.2) lib/ecto/repo/schema.ex:829: Ecto.Repo.Schema.dump_changes!/6
       (ecto 3.5.2) lib/ecto/repo/schema.ex:255: anonymous fn/15 in Ecto.Repo.Schema.do_insert/4
       test/uuid/ecto/type_test.exs:166: (test)

When actually using as Ecto Type `load` errors

** (ArgumentError) cannot load `<<125, 255, 53, 135, 116, 124, 73, 67, 132, 64, 237, 201, 117, 178, 26, 223>>`
as type {:parameterized, UUID.Ecto.Type, {:uuid6, [:random_bytes]}} for field `id` in schema Foo

When I switch load to accept a String and not just a binary UUID, then it works as intended.

Get rid of ExCoveralls warnings

Warnings from ExCoveralls:

warning: :cover.start/0 defined in application :tools is used by the current application but the current application does not directly depend on :tools. To fix this, you must do one of:

  1. If :tools is part of Erlang/Elixir, you must include it under :extra_applications inside "def application" in your mix.exs

  2. If :tools is a dependency, make sure it is listed under "def deps" in your mix.exs

  3. In case you don't want to add a requirement to :tools, you may optionally skip this warning by adding [xref: [exclude: :cover] to your "def project" in mix.exs

  lib/excoveralls/cover.ex:11: ExCoveralls.Cover.compile/1

and

warning: EEx.eval_file/2 defined in application :eex is used by the current application but the current application does not directly depend on :eex. To fix this, you must do one of:

  1. If :eex is part of Erlang/Elixir, you must include it under :extra_applications inside "def application" in your mix.exs

  2. If :eex is a dependency, make sure it is listed under "def deps" in your mix.exs

  3. In case you don't want to add a requirement to :eex, you may optionally skip this warning by adding [xref: [exclude: EEx] to your "def project" in mix.exs

Found at 2 locations:
  lib/excoveralls/html/view.ex:27: ExCoveralls.Html.View.render/1
  lib/excoveralls/html/view.ex:31: ExCoveralls.Html.View.partial/2

I've tried adding the options [xref: [exclude: [:cover, EEx]] to mix project as suggested in the warning above but it does not stop the warning from happening.