ruby on rails - How does db:schema:load affect future db:migrate actions -
let's i've got app bunch of migration files i'm getting ready deploy production first time. understand, have 2 options db on production server:
- a - run
db:migrate
, , have cycle through migrations hasn't yet run - b - run
db:schema:load
, , have build db schema file
i know b right choice fresh deployments, explained in schema.rb
comments:
# if need create application database on # system, should using db:schema:load, not running migrations # scratch. latter flawed , unsustainable approach (the more migrations # you'll amass, slower it'll run , greater likelihood issues).
what i'm wondering is, how affect migrations on production server going forward? example, if following in order:
- run
db:schema:load
on new production server. - change schema in development , push production.
- run
db:migrate
on production server
what happen? know use migrations more recent db:schema:load
action, or try run them all?
good question. answer migrations created after latest db:schema:load
event ever run.
the schema.rb file has version stamp associated it:
activerecord::schema.define(version: 20130928225041) ...
when run db:schema:load
, rails creates fresh database according schema.rb file, , @ same time populates schema_migrations
table migrations version number precede of schema.
so far can tell rails faking migrations until point, doesn't run them. (i tested out generating empty migration file, calling db:migrate
locally, inserting error migration file before deploying our server. on server, ran db:schema:load
, , result bad migration included in schema_migrations table if had been run, though had not.)
Comments
Post a Comment