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:
and check the API first! This way you won’t have any problem.
cheers,
Zoltn
On 27 November 2010 12:45, Michael P. [email protected] wrote:
On 27 November 2010 03:14, daze [email protected] wrote:
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
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
On 27 November 2010 12:57, Colin L. [email protected] wrote:
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.
Sorry for any confusion. I was answering the two different questions
the OP seemed to ask:
-
can you set up different DBs for dev/test/production?
Yes you can, and it’s very easy. -
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
Sorry for any confusion. I was answering the two different questions
the OP seemed to ask:
- can you set up different DBs for dev/test/production?
Yes you can, and it’s very easy.- 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?
On 27 November 2010 16:05, daze [email protected] wrote:
Sorry for any confusion. I was answering the two different questions
the OP seemed to ask:
- can you set up different DBs for dev/test/production?
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)
On 27 November 2010 03:14, daze [email protected] wrote:
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 
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