Ideally, migrations will be able to transform the database structure (and data added at any stage along the way) from nothing to the final state. In this case, seed data could go in migrations.
However, I think it's not uncommon to have migrations (especially for data) that are dependent on model code, which itself can change. In that case, migrations still provide a valuable service in being able to roll back and forward between recent versions of the database. You probably didn't want to deploy a new instance by running all migrations anyway. That's where the schema comes in. Schema + seeds should == a fresh database, ready to use. I use migrations for structure and data changes, and keep them isolated from models wherever that can be done easily. I depend on the schema + seeds always producing a fresh, working DB. I think that's usually a good way to go. I'd reconsider the approach if I had some (rare) application where data is more critical, and a "fresh" DB isn't useful. Cheers, Chris On Fri, Sep 23, 2011 at 9:27 AM, Tianwen Chen <[email protected]> wrote: > And in summary, the best practice I reckon is: > > Use seed at initial stage. Use migration after initial stage. > > Tian > > On Sep 23, 11:05 am, Tianwen Chen <[email protected]> wrote: >> Hi everyone, >> >> I just want to raise a discussion as titled and try to find out some >> best practices. >> >> I personally choose migration over seed only when we need to make >> changes after the app is online. >> >> From what I can see, the purpose of seed is when you have a completely >> new database, you can populate essential data for the app to use. The >> purpose of migration is when you need to make changes to the database >> schema, or data which people don't suggest to. >> >> Let's now think about the following scenarios: >> 1. Initial stage of the app >> Apparently, you should use seed in here instead of migration. >> 2. The app is already in production running, and you need to populate >> more data for some of the tables. For example, need to add more >> categories for products. >> Here, you can use either seed or migration. But for seed, you need >> to identify the existing record in the database in case you might >> create duplicate records. >> 3. The app is already in production running, and you need to remove >> some data in the database. For example, the client wants to remove the >> products and as well as their categories. >> Here, you will prefer migration over seed. As seed shouldn't be >> used to remove data from literal. >> >> Let's now take a look at their benefits and drawbacks: >> >> Benefits of using seed: >> 1. separate the obligation of data populating from migration at >> initial stage, place the thing where it should be >> >> Drawbacks of using seed: >> 1. no timestamp, you can't trace the history when changes were made >> 2. have to prevent inserting duplicate records when you want to insert >> new record >> 2. no rollback as you just can't >> 3. it is not included in the db:migrate rake task, therefore, you have >> to run the db:seed every time after the deployment until you automate >> this process in capistrano. >> PS: by using seed_fu or other gems, you may now take off the second >> drawback. >> >> Benefits of using migration: >> 1. timestamp is provided >> 2. you can rollback the changes as you want >> 3. you can either insert, update, and delete data >> >> Drawbacks of using migration: >> 1. should separate the data changes and database schema changes. >> (Here, I want to say, even if I put the data manipulation in db >> migrate, there is no harm of doing this. If you want to argue this is >> messy, how does db migration doesn't look messy to you, the reason we >> want to have db migration is we wish to trace when we did the changes >> and whether we can revert. This is what seed not capable for.) >> >> Welcome to discuss:) >> >> Kind Regards, >> >> Tian > > -- > You received this message because you are subscribed to the Google Groups > "Ruby or Rails Oceania" group. > To post to this group, send email to [email protected]. > To unsubscribe from this group, send email to > [email protected]. > For more options, visit this group at > http://groups.google.com/group/rails-oceania?hl=en. > > -- You received this message because you are subscribed to the Google Groups "Ruby or Rails Oceania" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/rails-oceania?hl=en.
