Database deploying in production

Rails
1

Hello,

What are the good practices to deploy an Rails database in production?
It is
said that is unsafe to run database migrations in a production database,
instead we should use schema.rb and seed.rb scripts. As far as I know,
schema.rb can just be used to create initial schemas, so, what are the
procedures to update the database schema in production?

Thanks,
Gustavo

2

“Gustavo de Sá Carvalho H.” <gustavohonorato wrote in post
#969047:

Hello,

What are the good practices to deploy an Rails database in production?
It is
said that is unsafe to run database migrations in a production database,

That’s ridiculous. Where did you get that information?

instead we should use schema.rb and seed.rb scripts. As far as I know,
schema.rb can just be used to create initial schemas,

That’s correct. When you set up a new installation, run rake
db:schema:load instead of running all the migrations. But that’s the
only time you’d do that.

so, what are the
procedures to update the database schema in production?

Use the migrations. That’s what they’re for.

Thanks,
Gustavo

Best,

Marnen Laibow-Koser
http://www.marnen.org
[email protected]

3

On Fri, Dec 17, 2010 at 12:55 PM, Marnen Laibow-Koser
[email protected]wrote:

“Gustavo de S Carvalho H.” <gustavohonorato wrote in post
#969047:

Hello,

What are the good practices to deploy an Rails database in production?
It is
said that is unsafe to run database migrations in a production database,

That’s ridiculous. Where did you get that information?

Yes, I agree with you. It’s very strange, but I saw this information in
comments of generated schema.rb.

This file is auto-generated from the current state of the database.

Instead of editing this file,

please use the migrations feature of Active Record to incrementally

modify
your database, and

then regenerate this schema definition.

Note that this schema.rb definition is the authoritative source for

your
database schema. If you need

to create the application database on another system, you should be

using
db:schema:load, not running

all the migrations from scratch. The latter is a flawed and

unsustainable
approach (the more migrations

you’ll amass, the slower it’ll run and the greater likelihood for

issues).

It’s strongly recommended to check this file into your version control

system.

4

2010/12/17 Gustavo de S Carvalho H. [email protected]:

It is

then regenerate this schema definition.

Note that this schema.rb definition is the authoritative source for your

database schema. If you need

to create the application database on another system, you should be using

db:schema:load, not running

Note the use of the word create here. It is saying that when you
initially create the production db (or another) that you should use
the schema to create it. It is not saying that for ongoing changes
after the initial create that you should not use migrations.

Your original question was ‘what are the procedures to update the
database schema in production’ and the answer to that is use the
migrations that you used to update the development db.

Colin

5

“Gustavo de Sá Carvalho H.” <gustavohonorato wrote in post
#969077:

On Fri, Dec 17, 2010 at 12:55 PM, Marnen Laibow-Koser
[email protected]wrote:

“Gustavo de S Carvalho H.” <gustavohonorato wrote in post
#969047:

Hello,

What are the good practices to deploy an Rails database in production?
It is
said that is unsafe to run database migrations in a production database,

That’s ridiculous. Where did you get that information?

Yes, I agree with you. It’s very strange, but I saw this information in
comments of generated schema.rb.

You’re misinterpreting those comments.

This file is auto-generated from the current state of the database.

Instead of editing this file,

please use the migrations feature of Active Record to incrementally

modify
your database, and

then regenerate this schema definition.

In other words, don’t edit this file manually; let the schema dumper do
it.

Note that this schema.rb definition is the authoritative source for

your
database schema. If you need

to create the application database on another system,

Note: create the application DB, not update it.

you should be
using
db:schema:load, not running

all the migrations from scratch.

Note: from scratch. This only applies when you are creating the DB
for the first time.

The latter is a flawed and
unsustainable
approach (the more migrations

you’ll amass, the slower it’ll run and the greater likelihood for

issues).

That is correct.

It’s strongly recommended to check this file into your version control

system.

There is nothing here about not using migrations on the production
database once it’s been created.

Best,

Marnen Laibow-Koser
http://www.marnen.org
[email protected]

6

On Dec 17, 2010, at 10:58 AM, Marnen Laibow-Koser wrote:

production?

In other words, don’t edit this file manually; let the schema dumper

approach (the more migrations

you’ll amass, the slower it’ll run and the greater likelihood for

issues).

That is correct.

BUT if your migrations do anything that doesn’t get captured into db/
schema.rb, then you need to either use :sql for the dump (db/
schema.sql) or you DO want to run all the migrations to initialize.

–
Marnen Laibow-Koser
http://www.marnen.org
[email protected]

–

Rob B.
[email protected] http://AgileConsultingLLC.com/
[email protected] http://GaslightSoftware.com/

7

“The latter is a flawed and unsustainable approach (the more migrations
you’ll amass, the slower it’ll run and the greater likelihood for
issues).”

Ok, but I think this specific part of the comment suggests that we might
never use migrations on production. No one likes to use a “flawed and
unsustainable approach” in production. These are scary words.

On Fri, Dec 17, 2010 at 1:58 PM, Marnen Laibow-Koser

8

Rob B. wrote in post #969093:

On Dec 17, 2010, at 10:58 AM, Marnen Laibow-Koser wrote:

production?

In other words, don’t edit this file manually; let the schema dumper

approach (the more migrations

you’ll amass, the slower it’ll run and the greater likelihood for

issues).

That is correct.

BUT if your migrations do anything that doesn’t get captured into db/
schema.rb, then you need to either use :sql for the dump (db/
schema.sql) or you DO want to run all the migrations to initialize.

That’s correct. That’s why it’s vitally important to not write
migrations in such a way that the schema dumper can’t capture them
(plugins such as Foreigner are a big help in this respect).

Best,

Marnen Laibow-Koser
http://www.marnen.org
[email protected]

Sent from my iPhone

9

On Fri, Dec 17, 2010 at 2:48 PM, Marnen Laibow-Koser
[email protected] wrote:

It suggests nothing of the kind, since it’s specifically only talking
about creating the production DB.

No one likes to use a “flawed and
unsustainable approach” in production. These are scary words.

Taking things out of context is even scarier. :slight_smile:

Ok. It was just an tip to improve the comment.

10

“Gustavo de Sá Carvalho H.” <gustavohonorato wrote in post
#969091:

“The latter is a flawed and unsustainable approach (the more migrations
you’ll amass, the slower it’ll run and the greater likelihood for
issues).”

Ok, but I think this specific part of the comment suggests that we might
never use migrations on production.

It suggests nothing of the kind, since it’s specifically only talking
about creating the production DB.

No one likes to use a “flawed and
unsustainable approach” in production. These are scary words.

Taking things out of context is even scarier. :slight_smile:

On Fri, Dec 17, 2010 at 1:58 PM, Marnen Laibow-Koser

Best,

Marnen Laibow-Koser
http://www.marnen.org
[email protected]

Sent from my iPhone

11

On Fri, Dec 17, 2010 at 4:07 PM, Marnen Laibow-Koser
[email protected] wrote:

Taking things out of context is even scarier. :slight_smile:

Ok. It was just an tip to improve the comment.

Personally, I think the comment is pretty clear, but if you don’t, then
you might want to raise an issue on Lighthouse.

I really know that you think the comment is pretty clear to you, but
for people less experienced with Rails like me, it could be not clear.
Experienced developers most of the time thinks that the problem is
associetaded with user’s limited knowledge fo the domain. In other
hand, for developers with a little background in Human-Computer
interaction like me, I think that there is aways a better way to
express what I want to say, in a way which less experienced users
can’t understand it wrong.

12

“Gustavo de Sá Carvalho H.” <gustavohonorato wrote in post
#969112:

On Fri, Dec 17, 2010 at 2:48 PM, Marnen Laibow-Koser
[email protected] wrote:

It suggests nothing of the kind, since it’s specifically only talking
about creating the production DB.

No one likes to use a “flawed and
unsustainable approach” in production. These are scary words.

Taking things out of context is even scarier. :slight_smile:

Ok. It was just an tip to improve the comment.

Personally, I think the comment is pretty clear, but if you don’t, then
you might want to raise an issue on Lighthouse.

Best,

Marnen Laibow-Koser
http://www.marnen.org
[email protected]