Paul Lynch wrote: [...] > 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.
Right, although I suppose you could always dump the data to YAML or something if you needed to. > > Also, you might want occasionally to add a new field to the table > (another product code field) and compute initial values via a > migration. Yes. This is entirely appropriate (although for myself, I like to set a default value on the DB side if things lend themselves to that). Migrations are about state transitions, and this recalculation is part of getting the DB to the new consistent state. [...] > 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. Generally, you wouldn't be running the earlier migration with the later codebase. I confess that I'm having trouble coming up with a scenario in which you'd ever do this. > > 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. No need. As I implied above, just don't run old migrations with new model files. In general, you should be releasing often enough that this won't happen, and in any case, if problems arise, you can always apply one commit, run migrations, and then apply the next commit (assuming your developers are committing as frequently as they should be). > 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. No! Migrations are a fabulous tool for managing DB state. Work *with* them in the ways I've been describing, not against them. Disabling migrations in the way you are proposing suggests that something is wrong with your release process. Fix the problem rather than breaking your tools. :) > > --Paul > Best, -- Marnen Laibow-Koser http://www.marnen.org [email protected] -- Posted via http://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 -~----------~----~----~----~------~----~------~--~---
