Rails SeedMigrations: Like schema migrations, but for your data(engineering.harrys.com)
engineering.harrys.com
Rails SeedMigrations: Like schema migrations, but for your data
http://engineering.harrys.com/2014/06/09/seed-migrations.html
4 comments
We used a db/seeds.rb file mainly for fake data to get our development environments going until there is real user data to work with. Can you use SeedMigrations to have a set of dev seeds vs prod seeds?
We didn't design the gem to handle "dev" data, the idea was really to handle "real" data, such as Product in our case.
Though if you feel like there would be a use case for dev seeds, I would be happy to discuss that with you (either here/twitter/mail etc ...)
Hey, one of the engineers who built this over here, happy to answer any questions you have.
I currently just use regular Rails migrations for this. In fact, I've executed each of the examples you provided using database migrations. You mentioned not wanting to use the console or a one-off script, but why would I want to switch over to SeedMigrations from regular ActiveRecord migrations?
Another one of the engineers here. While using ActiveRecord migrations will work for production systems, when setting up development or test systems using rake db:schema:load will not actually insert those records. Since rake db:schema:load is simply loading the current schema from schema.rb, you will still have to add those records into seeds.
As an alternative approach; we take a similar view to the grandparent, but run a full set of migrations instead of just copying the schema.
It actually works quite well. The tradeoff being that it may take a little longer, but we're typically talking tenths of a second.
It actually works quite well. The tradeoff being that it may take a little longer, but we're typically talking tenths of a second.
Ah, interesting, thanks for the explanation - I was wondering the same thing as your parent. I always do db:migrate instead of db:schema:load, but I can see the advantages of avoiding that (particularly if you have tons and tons of migrations).
What is the difference between this and say the seed-fu gem? Is having historical data the main advantage, so you can do rollbacks and such?
While I haven't personally used seed-fu, it seems to solve a different problem. There are two main problems we're trying to solve here:
- Having the seeds.rb file mirror the records you need from production. You wouldn't want to to register your User model, since you don't want all your production users. You would want to register a model like Product.
- Being able to easily migrate data on our production systems. Being able to easily migrate (and rollback if something goes wrong) is key to having predictable deploys (for us at least).
- Having the seeds.rb file mirror the records you need from production. You wouldn't want to to register your User model, since you don't want all your production users. You would want to register a model like Product.
- Being able to easily migrate data on our production systems. Being able to easily migrate (and rollback if something goes wrong) is key to having predictable deploys (for us at least).
This is so useful, thanks! Can it get existing data from the database? Or does it only translate the seeds.rb file? I've been using https://github.com/rroblak/seed_dump in the past.
It's key to migrate seeds on a "clean" database. Any models you register will be exported from the database into the seeds file, so we usually rake db:reset before running rake seed:migrate on development systems. We actually built this gem almost a year into our current system, so our first bootstrap of this loaded all the records from our production database for the models we needed (products, shipping types, etc.), which gave us a clean seeds file to use on development and test systems.