Get ready for queue_classic 3.1 and it's build-in scheduling

[jipiboily]

This gem is relying on queue_classic 3.0 and if you have queue_classic-later, it will work with it.

What does it do? It's looking at the queue_classic-later table when you click on the "Scheduled Jobs" link at the top. With queue_classic 3.1 though, there is now built-in scheduling similar to what queue_classic-later did. That said, it has a different approach. All jobs are now in the queue_classic_jobs table. There is no table for scheduling anymore. We want to get the queue_classic_admin aligned with that. We want only the job ready to show by default and the "Scheduled Jobs" link should still show jobs that are scheduled for later.

You can get additional context in QueueClassic/queue_classic#217 and QueueClassic/queue_classic#228. Those PR in other queue_classic related project might also help a bit, maybe not either: rainforestapp/queue_classic_plus#4 and rainforestapp/queue_classic_matchers#1.

[mnp]

Greetings Queuers,

I've started getting oriented on the framework and on this issue, and I have a requirements question first. To what extent should queue_classic-later remain supported? I see three options.

• A: continue supporting queue_classic-later in addition to the new QC >= 3.1, as well as QC < 3.1. This would entail detecting which of them is appearing in the DB--like is currently being done by ApplicationHelper::has_qc_later()--and then we will have three paths through the code: has_qc_later, has_qc_3_1, and neither.
• B: Abandon qc_later now, migrating to 3.1 in one shot. So basically convert all the has_qc_later code to has_qc_3_1 code. This would support QC < 3.1 and QC>=3.1, but not qc-later. This would result in two code paths, much like currently.
• C: Fully part with history and remove all the version branching and just assume >=3.1. There would be only one code path to maintain.

Does this view even make sense? Also, to what degree should migration/upgrade/rollback be a concern? Thanks for any thoughts.

[jipiboily]

@mnp I was thinking just do the move to support queue_classic 3.1 and don't bother supporting qc-later anymore. I am leaning toward B here, but I am not against C to be honest.

We should be able to have a setup with queue_classic 3 and qc-later and upgrade to the new qc-admin easily, but I don't think any database migration should be necessary as the main app should drop those tables, not qc-admin.

[jipiboily]

A PR for this has been merged.