Personally I have never been comfortable with using seed at all, I am of the opinion that all data insertions and alterations should happen in migrations. I agree that the generally accepted use case for seed is for initial data load, however I would argue that what constitutes "initial data load" changes in most applications, running the risk of having the seed quickly become out of date.
Take the example of look-up data. When first creating the lookup table (in a migration), you then also create the seed data to populate it. This is then pushed to the development branch and the rest of the team gets that change. Now, before the application is ready for production release, the lookup table and data undergoes several changes. We now have 2 choices: 1. We change the seed so that it incorporates the new changes, wipe the development databases and start again. OR 2. As discussed above with data changes, we simply use the migrations to translate the data across so we have a consistent history of the database over the lifetime of the project. In my opinion the 2nd is much better, it minimises the file changes on each schema change, thus minimising the capacity for error. The 2nd also brings in a problem though.. the seeds are no longer relevant to run on initial deployment.. they need to be run at a specific step in the migration chain. I have not used seed_fu so I am not sure if it caters for this eventuality, however a cursory glance at the github page suggests not. Fortunately, though we already have something to do that: Migrations In short seeds seem superfluous to needs in a successful project to me. I look forward to hearing everyones views On 23 September 2011 11:39, Anthony Richardson <[email protected]> wrote: > 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. > -- 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.
