Single database schema maintenance story

[kyrofa]

I'm evaluating SolidQueue for our projects. We're currently using Que, which is another database-backed ActiveJob backend, but I like the look of SolidQueue more for a variety of reasons. At the moment, though, I have a hiccup on the schema maintenance story.

I'd like to continue using a single database, instead of adding more infrastructure dedicated to jobs (this is one of the appeals of SolidQueue and Que). If we need to scale up later, we can split it out at that point. However, SolidQueue's use of a database-wide schema instead of migrations means I don't love the maintenance story here. Yeah I can throw the schema into a migration today, but what happens tomorrow when you want to change the schema? I can't just copy the schema into another migration: I'll have to inspect the new schema and manually craft migrations to bring my database in line with the new expectations.

Can we improve upon this? This is something I actually thought Que did pretty well: when a release required a schema change, you would write a migration that looked like this:

class UpdateQueSchemaToVersion7 < ActiveRecord::Migration[7.0]
  def up
    Que.migrate!(version: 7)
  end

  def down
    Que.migrate!(version: 6)
  end
end

I'd be happy to add a feature like this, but what I'm struggling with here is how to support that migration approach while also supporting shipping a schema in the generator without having to write both. Thoughts?

[rosa]

Hey @kyrofa! If we change the schema in the future, we'll do that via migrations, not just by updating the schema. We'll provide separate migrations for that.

[kyrofa]

Ah, well then, my concern is invalid :) . Thanks @rosa.