Thanks, Marnen, for mentioning seed_fu-- that is an intriguing plugin, and I have been thinking about whether we could use it. I think we have a situation in which it would not work well for us-- for at least some of our tables.
As a concrete example, suppose you have a large table of product information. If the table is large, loading it from a fixture (or seed_fu file) could be slow, and anyway some of that information will probably be edited through a separate administrative web application, which would not be updating seed/fixture files. Also, you might want occasionally to add a new field to the table (another product code field) and compute initial values via a migration. In this case it is convenient to use a migration because: * you want to try out the change with the code that uses it in your development area before checking in * computing initial values for the new field might be very quick and easy with ruby code * you want the other developers to get the data change when they do an update of the project files If it is very important that the new product code field have a value for all records, you might put some validation code into the model class to prevent new records from being created without it. Doing so would break any earlier migration that created product records. I don't really see any solution to this problem except identifying which tables are like this and directly copying them (from a dump file) into the production database. The migrations that modify them can be coded so that they don't do anything when run on the production system, and that way the migrations can still be run to update other tables (e.g. user data tables) which cannot be copied. --Paul On Jun 12, 3:26 pm, Marnen Laibow-Koser <rails-mailing-l...@andreas- s.net> wrote: > Paul Lynch wrote: > > I was actually talking about updating an existing production > > database. In such a case, the migrations which would be run would be > > just the ones between the previous release and the current one. > > This should not cause problems in most cases. You mentioned that some > of the problems involved application data; either that sort of thing > should be removed from migrations or the migrations should provide for > it. (If you have more concrete examples, I'll try to see how I'd handle > them.) > > If by "application data" you mean things like tables of country codes or > shipping rates, these absolutely do not belong in migrations. Try > something like seed_fu. > > Basically, migrations should provide all the changes necessary to get > the DB from one consistent state to the next. If you are having > problems with migrations, then they probably do not adhere to this > guideline. > > > > > I have not tried your suggestion of rake db:schema:load but, judging > > by the contents of schema.rb, this would drop all of the tables and > > recreate them. We would lose both our application data and our user > > data. > > Right. > > > Perhaps I misunderstood how you were thinking to use that? > > You didn't misunderstand; I thought you were talking about a different > situation. > > Best, > -- > Marnen Laibow-Koserhttp://www.marnen.org > [email protected] > -- > Posted viahttp://www.ruby-forum.com/. --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Ruby on Rails: Talk" 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/rubyonrails-talk?hl=en -~----------~----~----~----~------~----~------~--~---
