Database deploying in production

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

"Gustavo de Sá Carvalho Honorato" <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,

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

"Gustavo de Sá Carvalho Honorato" <gustavohonorato wrote in post
#969077:

"Gustavo de S Carvalho Honorato" <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,

"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.

"Gustavo de Sá Carvalho Honorato" <gustavohonorato wrote in post
#969077:

"Gustavo de S Carvalho Honorato" <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.

*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.

#
# 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
marnen@marnen.org

--

Rob Biedenharn
Rob@AgileConsultingLLC.com http://AgileConsultingLLC.com/
rab@GaslightSoftware.com http://GaslightSoftware.com/

Rob Biedenharn wrote in post #969093:

"Gustavo de Sá Carvalho Honorato" <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,

"Gustavo de Sá Carvalho Honorato" <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:

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

"Gustavo de Sá Carvalho Honorato" <gustavohonorato wrote in post
#969112:

"Gustavo de Sá Carvalho Honorato" <gustavohonorato wrote in post
#969112:

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.

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.