I’m getting started with Phoenix and Ecto. From the
Ecto.Migration docs, this section sounds very promising:
Having to write both
down/0functions for every migration is tedious and error prone. For this reason, Ecto allows you to defined a
change/0callback with all of the code you want to execute when migrating and Ecto will automatically figure out the
However, when I create a relationship between two resources with the phoenix generators:
mix phx.gen.html Context Foo foos name mix phx.gen.html Context Bar bars foo_id:references:foos
The generated migration for
def change do create table(:bars, primary_key: false) do add :id, :binary_id, primary_key: true add :foo_id, references(:foos, on_delete: :nothing, type: :binary_id) timestamps() end create index(:bars, [:foo_id]) end
change by default and creates an index, nice.
mix ecto.migrate 19:43:20.788 [info] create table bars 19:43:20.819 [info] create index bars_foo_id_index
So far, so good. However, trying to roll back:
mix ecto.rollback 19:44:14.631 [info] == Running 20210114104254 MyApp.Repo.Migrations.CreateBars.change/0 backward 19:44:14.634 [info] drop index bars_foo_id_index ** (MyXQL.Error) (1553) (ER_DROP_INDEX_FK) Cannot drop index 'bars_foo_id_index': needed in a foreign key constraint
If I manually remove the constraint, the rollback works.
Does this mean that when using generators with
references, I need to re-write the generated migration to use
down if I want these operations to be reversible? Is there a reason the generator doesn’t use
down for this by default, which would make it reversible? Or are constraints generally treated as irreversible?