Changes in schema usage/assumptions from `delayed_job`?
stesen-wefunder opened this issue · comments
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?
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.)
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!