30 replies

Differences between UUID primary keys in Ecto vs Ash

As far as I can tell, the Ash Resource special attribute

uuid_primary_key

uuid_primary_key

unwraps into:

attribute :id, :uuid do
  writeable? false
  default &Ash.UUID.generate/0
  primary_key? true
  allow_nil? false
end

attribute :id, :uuid do
  writeable? false
  default &Ash.UUID.generate/0
  primary_key? true
  allow_nil? false
end

Ash.UUID.generate/0

Ash.UUID.generate/0

seems to be a passthrough to

Ecto.UUID.generate()

Ecto.UUID.generate()

. What I found unexpected was the migration files.

Echo's migration file looks like:

...
def change do
  create table(:posts, primary_key: false) do
    add :id, :binary_id, primary_key: true
    ...
  end
end

...
def change do
  create table(:posts, primary_key: false) do
    add :id, :binary_id, primary_key: true
    ...
  end
end

Ash's migration file looks like:

def up do
  create table(:posts, primary_key: false) do
    add :id, :uuid, null: false, default: fragment("uuid_generate_v4()"), primary_key: true
    ...
  end
end

def up do
  create table(:posts, primary_key: false) do
    add :id, :uuid, null: false, default: fragment("uuid_generate_v4()"), primary_key: true
    ...
  end
end

I'm not entirely sure if the functionality will all be the same at the end of the day. Reading docs and source code, it seems like Postgrex treats

:binary

:binary

:binary_id

:binary_id

, and

:uuid

:uuid

similarly when ran by Ecto SQL, but I'm not sure.

The most surprising is the

:default

:default

option in Ash's implementation. It hard-codes a Postgres DB function as a default value even though

:primary_key

:primary_key

option is set (which I think inherently makes the field non-nullable in most databases.

The reason I'm worried about it is because I'm interested in using UUIDv7 for my PKs. That function may never run if generating UUIDs in Elixir-land, but it seems off to be there.

Ash Framework•3y ago•

30 replies

Korbin

Differences between UUID primary keys in Ecto vs Ash

As far as I can tell, the Ash Resource special attribute

uuid_primary_key

uuid_primary_key

unwraps into:

attribute :id, :uuid do
  writeable? false
  default &Ash.UUID.generate/0
  primary_key? true
  allow_nil? false
end

attribute :id, :uuid do
  writeable? false
  default &Ash.UUID.generate/0
  primary_key? true
  allow_nil? false
end

Ash.UUID.generate/0

Ash.UUID.generate/0

seems to be a passthrough to

Ecto.UUID.generate()

Ecto.UUID.generate()

. What I found unexpected was the migration files.

Echo's migration file looks like:

...
def change do
  create table(:posts, primary_key: false) do
    add :id, :binary_id, primary_key: true
    ...
  end
end

...
def change do
  create table(:posts, primary_key: false) do
    add :id, :binary_id, primary_key: true
    ...
  end
end

Ash's migration file looks like:

def up do
  create table(:posts, primary_key: false) do
    add :id, :uuid, null: false, default: fragment("uuid_generate_v4()"), primary_key: true
    ...
  end
end

def up do
  create table(:posts, primary_key: false) do
    add :id, :uuid, null: false, default: fragment("uuid_generate_v4()"), primary_key: true
    ...
  end
end

I'm not entirely sure if the functionality will all be the same at the end of the day. Reading docs and source code, it seems like Postgrex treats

:binary

:binary

:binary_id

:binary_id

, and

:uuid

:uuid

similarly when ran by Ecto SQL, but I'm not sure.

The most surprising is the

:default

:default

option in Ash's implementation. It hard-codes a Postgres DB function as a default value even though

:primary_key

:primary_key

Differences between UUID primary keys in Ecto vs Ash

Similar Threads

Differences between UUID primary keys in Ecto vs Ash

Similar Threads

Similar Threads

Similar Threads