polymorphic_on_delete option results in never-ending migration cycle

[mindok]

Describe the bug
When using the polymorphic_on_delete option as described in #189, the snapshots are generated with the name of the reference set to :delete (the option set for polymorphic_on_delete). It appears that using an atom for the reference name results in a string <> atom comparison at some point and a new migration is generated for the relationship each time the generate_migrations mix task is run.

Using :delete for the name also has the potential to create multiple constraints with the same name for a single table which is going to cause other dramas...

The up migration drops the constraint named "delete" and creates a new, identical one named :delete.
The down migration does the reverse.

For example:

  def up do
    drop constraint(:event_locations, "delete")

    alter table(:event_locations) do
      modify :resource_id,
             references(:events,
               column: :id,
               name: :delete,
               type: :uuid,
               on_delete: :delete_all
             )
    end
  end

...

  def down do
    drop constraint(:event_locations, :delete)

    alter table(:event_locations) do
      modify :resource_id,
             references(: events,
               column: :id,
               name: "delete",
               type: :uuid,
               on_delete: :delete_all
             )
    end
  end

I suspect AshPostgres.DataLayer.Info.polymorphic_name/1 is at fault - it returns the setting rather than a name. The call to it in AshPostgres.MigrationGenerator.get_snapshots/2 can probably just be removed until #189 is done.

To Reproduce
As per #189, but generate migrations.

Expected behavior
Once the migration has been generated, ash_postgres.generate_migrations --check should give the all clear.

[mindok]

I'll have a crack at this to warm up for the other 😄

[zachdaniel]

Fixed in a60dbf1