6 replies

migration_defaults being "rewritten" by another resource

In my system, I have 2 contexts/apis that uses the same table and have a field in common.

The first is the

User

User

resource inside the

Accounts

Accounts

api:

defmodule Accounts.User do
  attributes do
    attribute :referral_code, :uuid do
      allow_nil? false

      generated? true
    end
  end

  postgres do
    table "users"

    migration_defaults referral_code: "fragment(\"uuid_generate_v4()\")"

    repo TeacherCompanion.Repo
  end
end

defmodule Accounts.User do
  attributes do
    attribute :referral_code, :uuid do
      allow_nil? false

      generated? true
    end
  end

  postgres do
    table "users"

    migration_defaults referral_code: "fragment(\"uuid_generate_v4()\")"

    repo TeacherCompanion.Repo
  end
end

As you can see, I have a

migration_defaults

migration_defaults

function call where I specify that an uuid need to be automatically generated for the

referral_code

referral_code

field.

I also have another resource called

Referrer

Referrer

which is inside my

Referrals

Referrals

api:

defmodule Referrals.Referrer do
  attributes do
    ...

    attribute :referral_code, :uuid do
      allow_nil? false

      writable? false
    end
  end

  postgres do
    table "users"

    repo TeacherCompanion.Repo
  end
end

defmodule Referrals.Referrer do
  attributes do
    ...

    attribute :referral_code, :uuid do
      allow_nil? false

      writable? false
    end
  end

  postgres do
    table "users"

    repo TeacherCompanion.Repo
  end
end

This resource also has the

referral_code

referral_code

field, but it is only a "read-only" field. the thing is that in this resource I'm not specifying the

migration_defaults

migration_defaults

function call since it would be redundant as I already did that in the other resource and I would just be duplicating code and making maintenance more bothersome.

The problem is that since

Referrer

Referrer

don't have the

migration_defaults

migration_defaults

function call, when I generate the migration for both resources, Ash will simply ignore the

User

User

migration_defaults

migration_defaults

and not add any default for the

users

users

table

referral_code

referral_code

field.

I'm not sure if this is by design, but it feels very odd to me since I was expecting that Ash would simply "merge" both resource configurations into the

users

users

table.

The only workaround I found was to duplicate the

migration_defaults

migration_defaults

function call in both resources, but that kinda of eliminates the benefits of breaking a table into subsets (contexts) since in the end I need to duplicate a lot of code that shouldn't be needed in the first place.

migration_defaults being "rewritten" by another resource

In my system, I have 2 contexts/apis that uses the same table and have a field in common.

The first is the

User

User

resource inside the

Accounts

Accounts

api:

defmodule Accounts.User do
  attributes do
    attribute :referral_code, :uuid do
      allow_nil? false

      generated? true
    end
  end

  postgres do
    table "users"

    migration_defaults referral_code: "fragment(\"uuid_generate_v4()\")"

    repo TeacherCompanion.Repo
  end
end

defmodule Accounts.User do
  attributes do
    attribute :referral_code, :uuid do
      allow_nil? false

      generated? true
    end
  end

  postgres do
    table "users"

    migration_defaults referral_code: "fragment(\"uuid_generate_v4()\")"

    repo TeacherCompanion.Repo
  end
end

As you can see, I have a

migration_defaults

migration_defaults

function call where I specify that an uuid need to be automatically generated for the

referral_code

referral_code

field.

I also have another resource called

Referrer

Referrer

which is inside my

Referrals

Referrals

api:

defmodule Referrals.Referrer do
  attributes do
    ...

    attribute :referral_code, :uuid do
      allow_nil? false

      writable? false
    end
  end

  postgres do
    table "users"

    repo TeacherCompanion.Repo
  end
end

defmodule Referrals.Referrer do
  attributes do
    ...

    attribute :referral_code, :uuid do
      allow_nil? false

      writable? false
    end
  end

  postgres do
    table "users"

    repo TeacherCompanion.Repo
  end
end

This resource also has the

referral_code

referral_code

field, but it is only a "read-only" field. the thing is that in this resource I'm not specifying the

migration_defaults

migration_defaults

function call since it would be redundant as I already did that in the other resource and I would just be duplicating code and making maintenance more bothersome.

The problem is that since

Referrer

Referrer

don't have the

migration_defaults

migration_defaults

function call, when I generate the migration for both resources, Ash will simply ignore the

User

User

migration_defaults

migration_defaults

and not add any default for the

users

users

table

referral_code

referral_code

field.

I'm not sure if this is by design, but it feels very odd to me since I was expecting that Ash would simply "merge" both resource configurations into the

users

users

table.

The only workaround I found was to duplicate the

migration_defaults

migration_defaults

migration_defaults being "rewritten" by another resource

migration_defaults being "rewritten" by another resource

Similar Threads

Similar Threads

Similar Threads