I use migration to transform data as part of schema changes. (e.g creating default values for new columns, or copying data from one table to another if it is being broken out in to a new table). I use rake task to change data if part of a business change. I ensure the rake task is idempotent.
Cheers, Anthony On Fri, Sep 23, 2011 at 10:57 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.
