Breaks with Repos configured to use UUIDs by default

[cdcme]

Problem Description

With an Ecto.Repo configured to use UUIDs for new migrations by default, like:

config :my_app, MyApp.Repo,
  ... other config ...
  migration_primary_key: [
    id: :uuid,
    type: :binary_id,
    autogenerate: true
  ],
... other config ...

the jobs table is created with a PK id column of type UUID, as expected, but the application code is expecting an integer, preventing jobs from being created, even if explicitly given a UUID.

Expected Behavior

Libraries should "play nice" with existing Ecto.Migration and Ecto.Repo configuration options, and should honor the configuration of the host application's Repo with respect to id column type and autogeneration.

Workaround

It isn't possible to use a UUID at all, so the only workaround available is to create the table with a primary ID type of integer. The most straightforward way to do this is to simply comment out the relevant configuration before running the migration that creates the job queue table.

Potential Solutions

• Allow for custom implementations via protocols?
• Make the migration generator create the migrations alongside application's migrations, where they can be customized?
• Allow for configuration of library field type for id column in config.exs
• Inherit field types from MyApp.Repo configuration, allowing overrides via library configuration?

[mbuhot]

@carlodicelico Thanks for the detailed bug report 👍
I wasn't even aware of migration_primary_key, it looks like it was introduced in ecto 2.2 just after ecto_job was first created.

I'm not sure I understand why you might want non-integer primary keys on the jobs tables.
I'd prefer to avoid the complexity and just explicitly declare the primary key in the migration, something like:

 create table(:jobs, primary_key: false) do
      add :id, :id, primary_key: true

or just use a SQL string in the migration to be completely explicit.

[cdcme]

Agreed, it's not really necessary for the jobs table to have the same PK type as long as having migration_primary_key set in the repo's config doesn't break anything. I guess it might be possible to have key collisions if the application database is sharded, but that seems more like bikeshedding than real or likely scenario. Your solution is perfect!