Every author of the free software obviously has rights to full control of the scope of their project.

That being said, I regret that we have switched from good_job (https://github.com/bensheldon/good_job). The thing is - Basecamp is a MySQL shop and their policy is not to accept RDMS engine specific queries. You can see in their issues in Github that they try to stick "universal" SQL and are personally mostly concerned how it performs in MySQL(https://github.com/rails/solid_queue/issues/567#issuecomment... , https://github.com/rails/solid_queue/issues/508#issuecomment...). They also still have no support for batch jobs: https://github.com/rails/solid_queue/pull/142 .

▲

chasd00 2 hours ago | parent | next [-]

If you’re tied so tight to MySQL that you’re labeled a “MySQL shop” then it seems logical to use MySQL specific features. I must be missing something.

	▲	jrochkind1 an hour ago \| parent [-]
		It's reasonable for basecamp, but the complaint of GP is that basecamp controls what is the Rails standard/default solution intended to be useful for multiple rdbms, without being willing to put rdbms-specific logic in rdbms-specific adapters.

▲

jrochkind1 an hour ago | parent | prev | next [-]

Can you be more specific about the issues you have run into that make you advise GoodJob over SolidQueue?

I am (and have been for a while, not in a hurry) considering them each as a move off resque.

The main blocker for me with GoodJob is that it uses certain pg-specific features in a way that makes it incompatible with transaction-mode in pgbounder -- that is, it requires persistent sessions. Which is annoying, and is done to get some upper-end performance improvements that I don't think matter for my or most scales. Otherwise, I much prefer GoodJob's development model, trust the maintainer's judgement more, find the code more readable, etc. -- but that's a big But for me.

▲

downsplat 3 hours ago | parent | prev | next [-]

That sounds like the worst of possible worlds! At $WORK we're also on mysql, but I don't know what I would do without engine-specific queries. For one, on complex JOINs, mysql sometimes gets the query plan spectacularly wrong, and even if it doesn't now, you can't be sure it won't in the future. So for many important queries I put the tables in the intended order and add a STRAIGHT_JOIN to future-proof it and skip query planner complexity.

▲

brightball 2 hours ago | parent | prev | next [-]

Agreed. good_job is the ideal approach to a PG backed queue.

▲

robertlagrant 2 hours ago | parent | prev [-]

> their policy is not to accept RDMS engine specific queries

Why? Is it so they can switch in future?

	▲	cl0ckt0wer 2 hours ago \| parent [-]
		Then they don't have to troubleshoot advanced queries.