Types of db for environments - same or different?

Should the types of databases for development, testing, and production
all be the same?

Is it okay to have, for example, sqlite3 for development and testing,
and mysql2 for production? Is that doable/common/not too hard to
configure?

This just bit me on some hand-coded SQL, migrating from SQLite to MySQL and I didn't get the same results from a query. If you're never touching hand-written SQL or conditions parameters, then you should be fine with mix-and-match. But to be absolutely certain, then you can't beat using the same database in all three environments.

Walter

Hi,
I think you can use different databases without any problem, just set
it in the database.yaml file. I think this is the only settings you
need, but it's wise to check the application.rb file, if any other
smart settings are available.

For hardcoding SQL use this tutorial:
http://guides.rubyonrails.org/active_record_querying.html
and check the API first! This way you won't have any problem.

cheers,
Zoltán

Is it okay to have, for example, sqlite3 for development and testing,
and mysql2 for production? Is that doable/common/not too hard to
configure?

It's perfectly doable, and perfectly okay, and apparently quite
common; just complete the appropriate sections of the database.yml
file for each of your environments.

Should the types of databases for development, testing, and production
all be the same?

"Should"? No... *don't* do it! Even though it is undoubtedly possible,
and lots of people do :slight_smile:
You will be making a total nightmare for yourself when code that
"works" in development "doesn't pass tests", or worse, code that
"passes tests" doesn't "run in production". There are too many
differences across dbs; reserved words, db contraints (like index name
sizes), and general SQL implementation [1]. Make your development
environment as close as possible to your production, and ideally have
your test environment be *identical* to production.

HTH

[1] Only a couple of weeks ago, there was a thread about a migration
that wouldn't run for someone, which ended up being that SQLite
wouldn't add not-null columns to an existing table without a default
value.... MySQL will :wink:

Is it okay to have, for example, sqlite3 for development and testing,
and mysql2 for production? Is that doable/common/not too hard to
configure?

It's perfectly doable, and perfectly okay, and apparently quite
common; just complete the appropriate sections of the database.yml
file for each of your environments.

I am a bit confused Michael, see below. Here you are saying it is ok
to have different db types.

Should the types of databases for development, testing, and production
all be the same?

"Should"? No... *don't* do it! Even though it is undoubtedly possible,
and lots of people do :slight_smile:

Now you are saying that that they must _not_ be the same. Methinks
you mistyped?

You will be making a total nightmare for yourself when code that
"works" in development "doesn't pass tests", or worse, code that
"passes tests" doesn't "run in production". There are too many
differences across dbs; reserved words, db contraints (like index name
sizes), and general SQL implementation [1]. Make your development
environment as close as possible to your production, and ideally have
your test environment be *identical* to production.

Here you say they should be the same I think (which I agree with
generally), yet right at the start you said it was ok for them to be
different.

Colin

Sorry for any confusion. I was answering the two different questions
the OP seemed to ask:
1) *can* you set up different DBs for dev/test/production?
Yes you can, and it's very easy.
2) *should* you do it?
No - in most cases.

The framework makes it easy to do, and sometimes you might have to
operate with different DB configurations (you might be developing for
a commercial DB you don't have installed locally to your dev
environment...), but given the choice, I would avoid it if at all
possible, and try to ensure my environments are all as similar as
possible.
You might choose to have a different test environment to take
advantage of running tests memory for fast performance - but you would
have to beware of failures of the testing environment (due to db
differences) which weren't necessarily problems with your application
- but if someone is running tests in RAM, they're probably more than
aware of this :wink:

Sorry for any confusion. I was answering the two different questions
the OP seemed to ask:
1) *can* you set up different DBs for dev/test/production?
Yes you can, and it's very easy.
2) *should* you do it?
No - in most cases.

I think, when you say "should you do it?" you mean "should you make
your databases different?" which is the confusion, because you
clearly explain that it's better TO MAKE THE DATABASES AS SIMILAR AS
POSSIBLE (right?).
So actually, my question, which was "Should the types of databases for
development, testing, and production *all be the same*?" should get
the answer, "Yes, the databases should be the same," correct?

Bottom line: Although many Rails developers use different types of
databases for the three environments, it is best to use the same type
of database - e.g. MySql2 - for all three environments.

Sound good?

Yes.

Sorry again - of course, all the environments use different databases
(even if they're all MySQL), but if you use MySQL for dev, SQLite for
test, and MSSQL for production, your life will be more complicated
than had you used MSSQL for all (as that's what the production DB is,
for better or worse)
:wink: