[weljoda]

Migration statement order when recreating an unnamed custom index (ash_archival)

Contributor checklist

Leave anything that you believe does not apply unchecked.

• I accept the AI Policy, or AI was not used in the creation of this PR.
• Bug fixes include regression tests
• Chores
• Documentation changes
• Features include unit/acceptance tests
• Refactoring
• Update dependencies

Hi everybody, I created a fix for the following issue:

I encountered an issue with ash.codegen when adding ash_archival to my project. With base_filter_sql "deleted_at IS NULL", every custom index gets a new where, so codegen recreates it. But it emits the create before the drop:

def up do
  create index(:containers, [:path], using: "GIST", where: "deleted_at IS NULL")
  drop_if_exists index(:containers, [:path])
end

def down do
  create index(:containers, [:path], using: "GIST")
  drop_if_exists index(:containers, [:path])
end

Both indexes have the same name (containers_path_index), so the create fails with "relation already exists".

OperationDeps already orders "drop before create" for custom indexes with an explicit name:, but leaves out unnamed ones on purpose, assuming they would wrongly share a nil key. Using AshPostgres.CustomIndex.name/2 provides a name for the index we can use here.

Known gap: with attribute multitenancy, the real index name includes the tenant column but the name built here doesn't, so a rare case could still come out in the wrong order. That might be a separate PR.

Greetings Johannes

[zachdaniel]

🚀 Thank you for your contribution! 🚀