Rails - Nov 2010 - 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?

-- 
You received this message because you are subscribed to the Google Groups
"Ruby on Rails: Talk" group.
To post to this group, send email to
rubyonrails-talk-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org
To unsubscribe from this group, send email to
rubyonrails-talk+unsubscribe-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org
For more options, visit this group at
http://groups.google.com/group/rubyonrails-talk?hl=en.

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

On Nov 26, 2010, at 10:14 PM, daze wrote:
> 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?
>
> -- 
> You received this message because you are subscribed to the Google  
> Groups "Ruby on Rails: Talk" group.
> To post to this group, send email to rubyonrails- 
> talk-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org
> To unsubscribe from this group, send email to
rubyonrails-talk+unsubscribe-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
> .
> For more options, visit this group at
http://groups.google.com/group/rubyonrails-talk?hl=en
> .
>
-- 
You received this message because you are subscribed to the Google Groups
"Ruby on Rails: Talk" group.
To post to this group, send email to
rubyonrails-talk-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org
To unsubscribe from this group, send email to
rubyonrails-talk+unsubscribe-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org
For more options, visit this group at
http://groups.google.com/group/rubyonrails-talk?hl=en.

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

On nov. 27, 03:14, daze
<dmonopol...-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
wrote:
> 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?
-- 
You received this message because you are subscribed to the Google Groups
"Ruby on Rails: Talk" group.
To post to this group, send email to
rubyonrails-talk-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org
To unsubscribe from this group, send email to
rubyonrails-talk+unsubscribe@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/rubyonrails-talk?hl=en.

On 27 November 2010 03:14, daze
<dmonopoly10-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
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 ;-)

-- 
You received this message because you are subscribed to the Google Groups
"Ruby on Rails: Talk" group.
To post to this group, send email to
rubyonrails-talk-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org
To unsubscribe from this group, send email to
rubyonrails-talk+unsubscribe@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/rubyonrails-talk?hl=en.

On 27 November 2010 12:45, Michael Pavling
<pavling-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
wrote:
> On 27 November 2010 03:14, daze
<dmonopoly10-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> 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

-- 
You received this message because you are subscribed to the Google Groups
"Ruby on Rails: Talk" group.
To post to this group, send email to
rubyonrails-talk-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org
To unsubscribe from this group, send email to
rubyonrails-talk+unsubscribe@googlegroups.com.
For more options, visit this group at
http://groups.google.com/group/rubyonrails-talk?hl=en.

On 27 November 2010 12:57, Colin Law
<clanlaw-gM/Ye1E23mwN+BqQ9rBEUg@public.gmane.org>
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:
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 ;-)

-- 
You received this message because you are subscribed to the Google Groups
"Ruby on Rails: Talk" group.
To post to this group, send email to
rubyonrails-talk-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org
To unsubscribe from this group, send email to
rubyonrails-talk+unsubscribe-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org
For more options, visit this group at
http://groups.google.com/group/rubyonrails-talk?hl=en.

> 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?

-- 
You received this message because you are subscribed to the Google Groups
"Ruby on Rails: Talk" group.
To post to this group, send email to
rubyonrails-talk-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org
To unsubscribe from this group, send email to
rubyonrails-talk+unsubscribe-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org
For more options, visit this group at
http://groups.google.com/group/rubyonrails-talk?hl=en.

On 27 November 2010 16:05, daze
<dmonopoly10-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
wrote:
>> 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?
>
> 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)
;-)

-- 
You received this message because you are subscribed to the Google Groups
"Ruby on Rails: Talk" group.
To post to this group, send email to
rubyonrails-talk-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org
To unsubscribe from this group, send email to
rubyonrails-talk+unsubscribe-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org
For more options, visit this group at
http://groups.google.com/group/rubyonrails-talk?hl=en.