Migration generator splitting composite primary keys
\ ឵឵឵:
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