Hacker News Reader

Comment by jacob-s-son | Hacker News Reader

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 .

View on HN

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.

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.

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.

Ooh. That's a dealbreaker, ladies!

I thought I was the only one who remembers this one.

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.

The first one that jumps out at me when I've evaluated it are batches (a Sidekiq Pro feature, though there are some Sidekiq plugins that support the same)

Ah neat, I didn't realize GoodJob had batches, great.

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

I have no opinion whatsoever yet on SolidQueue, but I'm having a blast with good job. Stuff works pretty well.

Don't you think the officially supported Rails modules should work with all the RDMS engines that Rails supports? What would a MySQL based Rails app use if the official supported module didn't support it?

I think the suggestion is that one can have rdbms-specific optimizations while still keeping a standards-compliant base implementation.

Both MySQL and Postgresql could get their own optimizations.

Oh, weird, they won't even allow functionally equivalent optimizations? That seems silly.

I was responding to Rails not officially supporting good_job, though, which appears to be a Postgres-only tool.

In the SQL world even simple things like booleans are RDMS engine specific so I have no idea how that is supposed to work.

> their policy is not to accept RDMS engine specific queries

Why? Is it so they can switch in future?

Earlier Rails avoided database specific features so apps could stay portable using only ActiveRecord. Since then Rails has added much better PostgreSQL support: JSON/JSONB, hstore, array columns, GIN/GiST indexes.

Then they don't have to troubleshoot advanced queries.

I made the switch on a new project and I don't regret it but it's still early days software despite the marketing. Concurrency control is fantastic, but it doesn't always work. I've woken up to see all threads occupied with a job that should be concurrency of 1.

I've also run into issues where a db connection pool is filled up and solid queue silently fails. No error or logs, just stops polling forever until manual restart. Far from ideal.

But, I can live with it. I am going for minimal maintenance, and the ability to run solid queue under puma inside rails on cloud run is just so easy. Having ~3 solid queue related issues a year is acceptable for my use case, but that doesn't mean it will be ok for others.

Reply on news.ycombinator.com