search

bkeepers / qu

a Ruby library for queuing and processing background jobs.
MIT License
505 stars 50 forks source link

Create an SQL backend #8

Closed bkeepers closed 10 years ago

bkeepers commented 12 years ago

SQL databases don't make the best queues, but for smaller apps with lower throughput, they work just fine.

It would be nice to have an SQL backend that is as close to the driver as possible, but I'm not aware of any stand-alone libraries that abstract the various database drivers.

laserlemon commented 12 years ago

What's wrong with using activerecord? It's familiar and well-tested. Or you could drop to the arel level.

bkeepers commented 12 years ago

Nothing, really. It'd just be nice to get closer to the driver if possible. I realize that's a lot easer with redis and mongo than it is sql databases, so might just have to settle for ActiveRecord.

danielmorrison commented 12 years ago

Bonus points if you call the gem 's-qu-l'

bkeepers commented 12 years ago

or se-qu-al

luislavena commented 12 years ago

What about using DataObjects and do_* adapters instead? they offer an standardized interface to different databases.

bkeepers commented 12 years ago

Does it play nice with ActiveRecord? I'd probably prefer to have two separate backends, one for DO and another for ActiveRecord.

luislavena commented 12 years ago

DataObjects powers DataMapper but is not DataMapper. Think of it as the newer DBI.

I thought you wanted a SQL close to the metal as possible, not a pluggable one that you can change the model for one in your current application (mostly using ActiveRecord-users).

bkeepers commented 12 years ago

Gotcha. I do prefer something closer to the metal. I've never used it. I'm not opposed to having a qu backend for it if people would use it.

jnunemaker commented 10 years ago

Certainly not opposed to this, but I am not interested in maintaining it. If anyone tackles this, just do it in your own repo/gem (qu-sql, qu-ar, etc.).