Code of Conduct

• I agree to follow this project's Code of Conduct

AI Policy

• I agree to follow this project's AI Policy, or I agree that AI was not used while creating this issue.

Versions

Elixir 1.18.4 (compiled with Erlang/OTP 28)
Ash 3.5.28
ash_postgres 2.6.11

Operating system

macOS 13.6.3 (22G436)

Current Behavior

When creating a new resource and defining at least these blocks:

defmoduleAshPostgresRollback.Domain.SecondResourcedouseAsh.Resource,otp_app::ash_postgres_rollback,domain:AshPostgresRollback.Domain,data_layer:AshPostgres.DataLayerpostgresdotable"second_resources"repoAshPostgresRollback.Reporeferencesdoreference:first_resource,deferrable::initiallyendend# skiprelationshipsdobelongs_to:first_resource,AshPostgresRollback.Domain.FirstResourceendend

ash.codegen will bundle the creation of a table for the resource, as well as the creation of the foreign key & adjustment of theDEFERRABLE behaviour into the same migration. This work in theup direction just fine (it first creates the table, then the FK, then alters the constraint), but in thedown direction, the generated migration first drops the constraint, then the table, then tries to alter the constraint on an already dropped table:

defmoduleAshPostgresRollback.Repo.Migrations.SecondResourcedo# skipdefdowndodrop(constraint(:second_resources,"second_resources_first_resource_id_fkey"))drop(table(:second_resources))execute("ALTER TABLE second_resources ALTER CONSTRAINT second_resources_first_resource_id_fkey DEFERRABLE INITIALLY DEFERRED")endend

Reproduction

I prepared a sample GitHub repo that demonstrates the issue,available here. The linked migration shows that it first attempts to drop the tablesecond_resources, then it tries to alter a constraint on an already dropped table, resulting in a failure.

(Please excuse the nonsensical resources in the sample repo, and the strange formatting of migrations 😬)

Expected Behavior

I think there’s probably a bunch of solutions here, not sure which one is the best one…

• TheALTER CONSTRAINT statement could be placed at the top of thedown block, thus making thedown block truly in a reverse order from theup block
• The changes could be split into two migrations, one to create the tables, one to alter the constraint settings, then correct rollback behaviour would be achieved automatically?
• (Sidenote?) Perhaps it should be noted that bothup anddown blocks (as shown in the sample repo) make the constraintDEFERRABLE INITIALLY DEFERRED, so the rollback behaviour wouldn’t even truly restore the previous/original setting (I believeINITIALLY DEFERRED is not the default value… I think)