Migration generator splitting composite primary keys

\ ឵឵឵
2023-04-20

\ ឵឵឵:

Before, I believe the recommendation was to do many_to_many relationships like so:

  relationships do
    belongs_to :resource_a, App.ResourceA, primary_key?: true, allow_nil?: false
    belongs_to :resource_b, App.ResourceB, primary_key?: true, allow_nil?: false
  end

But now this results in:

** (Postgrex.Error) ERROR 42P16 (invalid_table_definition) multiple primary keys for table "resourcea_resourceb" are not allowed
    (ecto_sql 3.10.1) lib/ecto/adapters/sql.ex:913: Ecto.Adapters.SQL.raise_sql_call_error/1
    (elixir 1.14.4) lib/enum.ex:1658: Enum."-map/2-lists^map/1-0-"/2
    (ecto_sql 3.10.1) lib/ecto/adapters/sql.ex:1005: Ecto.Adapters.SQL.execute_ddl/4
    (ecto_sql 3.10.1) lib/ecto/migration/runner.ex:327: Ecto.Migration.Runner.log_and_execute_ddl/3
    (ecto_sql 3.10.1) lib/ecto/migration/runner.ex:117: anonymous fn/6 in Ecto.Migration.Runner.flush/0
    (elixir 1.14.4) lib/enum.ex:2468: Enum."-reduce/3-lists^foldl/2-0-"/3
    (ecto_sql 3.10.1) lib/ecto/migration/runner.ex:116: Ecto.Migration.Runner.flush/0
    (ecto_sql 3.10.1) lib/ecto/migration/runner.ex:290: Ecto.Migration.Runner.perform_operation/3
make: *** [db-migrate] Error 1

I can confirm that it is splitting these into two separate add ... primary_key: true statements in the migrations, just spotted due to regenerating. Is there a different approach now, or is this a bug?

ZachDaniel:

That is a bug 🙂

ZachDaniel:

Can you try against the main branch of ash_postgres, and see if it does the same thing?

\ ឵឵឵:

Yep, hold on

\ ឵឵឵:

Looks good