Changes in schema usage/assumptions from `delayed_job`?

[Sam Cohen]

Hello again!

Thanks again for this awesome library. I've ended up with one more question as I dig through our code to evaluate switching.

In what ways have you changed either the schema of the delayed_jobs table, or the assumptions surrounding how it's used?

We have a number of places in our code which--whether or not this is something that should have been done--directly query the table.

Generally these do one of a few things:

• Query for last_error IS (NOT) NULL for monitoring errors
• Query for locked_at IS (NOT) NULL for monitoring current queue usage
• (This is the one I'm really worried about) Query for handler LIKE '%SomeJobClass%' to check for the number of instances of a particular job in the queue. This most often seems to be used to prevent enqueueing too many instances of expensive/side-effectful jobs at once.
• I've also found one file that... I think is trying to parse the handler column to get the name of each job in the queue, again for a reporting page.

Would you expect any of those queries, or queries against the table in general, to break? Does Delayed provide new/better ways to do any of these things? Are there any DB migrations that need to be run to switch libraries?

[Nathan Griffith]

Hi @stesen-wefunder! All of those queries should still work as expected! We haven't changed the table structure at all. (There's always a possibility that we will, but if we ever did, we'd be sure to broadcast it with a major version bump and transitional code to ensure that the table can be migrated with zero downtime.)

[Sam Cohen]

Awesome! I'm really happy with how compatible this still is!

Same as my other issue, feel free to leave this one open or close at your leisure. :)

Thanks!