issue #611 solution

[WillG2001]

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

[WillG2001]

Description

Fixes #611

When changing only the index? setting on a reference (e.g., from index?: true to index?: false), the migration generator was emitting unnecessary operations that dropped and re-added the same foreign key. The migration should only create or drop the index, not touch the foreign key.

Changes

• Added references_differ_beyond_index?/2 helper to detect when reference configurations differ only in the index? setting
• Updated alter_attribute_events to skip FK drop/alter operations when only index? differs
• Fixed RemoveReferenceIndex to properly pass old_multitenancy for correct index generation
• Added test case to verify index-only changes don't emit FK operations

How to test

1. Create a resource with a reference that has index?: true:

   postgres do
     references do
       reference(:post, index?: true)
     end
   end

2. Run mix ash_postgres.generate_migrations to create the initial migration (should include FK and index creation)

3. Change the reference to index?: false:

   postgres do
     references do
       reference(:post, index?: false)
     end
   end

4. Run mix ash_postgres.generate_migrations again

5. Verify the new migration:

• Contains drop_if_exists index(:table_name, [:reference_column])
• Does NOT contain drop constraint(:table_name, "..._fkey")
• Does NOT contain modify :reference_column, references(...)

The test case "changing only reference index? does not drop and re-add foreign key (issue #611)" in test/migration_generator_test.exs verifies this behavior.

[zachdaniel]

The changelog is automatically managed. Please remove this and I'll merge 🥳