For newer Rails projects, I’ve often found myself combining SQL with noSQL technologies, taking advantage of each solution where its strengths lie.

Sometimes you can even get away with your “NoSQL” needs using only an SQL product; Postgres offers hstore, which hits a good swath of use cases and is easily integrated into an ActiveRecord environment via Juan Maiz’s activerecord-postgres-hstore.

But when you need to combine, say, Postgresql with MongoDB, things get less pretty. For obvious reasons, most ORMs and ODMs only support associations within themselves. (DataMapper neatly works around this by supporting multiple data stores, so if you’re a DataMapper user, stop reading this and go read the much-overlooked “multiple data-store connections” documentation instead.) You start to miss the convenience of easily accessing associations that you get with a single-database stack. And so you end up writing glue code.

Maybe you write really simple glue code. Maybe you find yourself writing so much simple glue code that you adapt it into metaprogramming. Maybe you’ve even finally gone off the deep end and done some hideously clever monkey-patching to turn method_missing into the grand prize winner of the Bad Idea competition.

That’s why I wrote Consort. Tired of writing nearly-identical glue over and over, I went meta. And at the point I’d gone to that much work, I figured why not bundle it up into a gem and save the world’s supply of horses from the glue-hungry fists of the world’s Ruby developers? (Sorry, horses, but you’ll still have to contend with Python and Java users.)

Today marks the release of version 0.1.0.pre. All the association-y goodness of versions 0.0.1 through 0.0.3, now with the added goodness of MongoMapper. It’s on rubygems now; grab it, give it a spin, and hit me on github with any issues or feature requests!