RoR: efficiently testing a project with mysql and sqlite

I'd like to continually test and benchmark my RoR app running over both mysql and sqlite, and I'm looking for techniques to simplify that. Ideally, I'd like a few things:

• simultaneous autotest / rspec testing with mysql and sqlite versions of the app so I'll know right away if I've broken something
• a dependable construct for writing db-specific code, since I need to break into `ActiveRecord::Base.connection.select_all()` once in a while.

The latter seems easy, the former seems difficult. I've considered having two separate source trees, each with its own db-specific config files (e.g. Gemfile, config/database.yml) and using filesystem links to share all common files, but that might frighten and confuse git. 开发者_JS百科

A cleaner approach would be a command line switch to rails to say which configuration to use as rails starts up. Though it would be nice, I don't think such a command line switch exists

How do other people handle this?

If I were you, I would do two things:

1. Don't check database.yml into your code repo. It contains database passwords, and if you're working with other developers on different machines, it will be a headache trying to keep track of which database is on which machine. It's considered bad practice and not a habit you should get into.
2. For files that should be checked into source (Gemfile & Gemfile.lock), I would manage this using Git branches. I would have one master branch that uses one database. Then another branch that uses the other. If you are working off the master branch and have it setup with MySQL, you can just rebase or merge into the SQlite branch whenever you make code changes. As long as you're not writing a lot of database-specific queries, you shouldn't have conflict problems.

Okay, with just a couple of tweaks, there's a simple way to run your app and tests under any one of several databases. I describe the technique in:

RoR: how do I test my app against multiple databases?

It works well for me -- someone else might find it useful.