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