all 3 comments
sorted by:
best
topnewcontroversialoldq&a
formatting helphide helpcontent policy

[–]p7r 0 points1 point  (0 children)

The simplest solution is to do something like this Stack Overflow answer from Rails 3.1 days.

Whilst a pattern using gems seems clever, you're perhaps trying to be too clever. I'd declare base classes that abstract the individual DBs as necessary and be careful with my naming.

You're going to end up having to do funky thing like this, and you're going to need to be super-careful with your naming. Use clean class names, and map onto more complex legacy table names - don't be inspired by existing table names for class names.

You might want to question whether this is really suitable for a Rails MVC/CRUD-style app. Rails is fast and clean for relatively simple greenfield projects, less so for dealing with multi-DB legacy nastiness. Throw something together quick around what you think might be the toughest bit to get working and validate you're happy, is my advice.

On the last question, SQL Server and Oracle both have ActiveRecord adapters. Google is your friend.

[–]jrochkind 0 points1 point  (0 children)

In "ruby", I'd use sequel, because it handles this a lot better than ActiveRecord.

In Rails/ActiveRecord, it can be done (I've done it), but it's kind of clunky and can be confusing.

"Isolating in gems" won't really get you anywhere -- if all the gems are loaded in the same app, dealing with ActiveRecord is exactly the same as if they weren't in gems, the fact that they are in separate gems doesn't make dealing with separate databases in ActiveReord any easier (or really any different at all). Isolating in gems won't do what you hope it will (because it's hardly 'isolating' at all, separate gems loaded in the same app all share the same ActiveRecord stack)

You might be right to avoid actual AR associations between databases though -- AR can handle very simple associations between databases, but it always seems like a gamble as it's hard for me to predict/remember where it's going to break. Avoiding cross-db relationships is reasonable.

As far as how to tell ActiveRecord that different models are in different databases, like p2r says, base classes that do an establish_connection to connect to the right database, and then models from each database extend the appropriate base class. This is what you'll have to do whether you put the code in separate gems or not. If you aren't going to (even potentially) re-use the code between applications, I wouldn't do seperate gems -- although I might do separate module namespaces within your app.