On 4 March 2010 16:50, Hassan Schroeder <[email protected]> wrote: > On Thu, Mar 4, 2010 at 8:31 AM, Ivan Nastyukhin <[email protected]> wrote: >> Because migration for definition structure and manage it. > > Just repeating it doesn't make it valid. Again, *why* do you think that? >
Migrations are a "point in time" reference about the structure of a database. If they alter *data* then they are binding tightly to the models - and you can no longer have a later migration that adds/removes/renames columns, because those columns will be set in the data in an earlier migration. Similarly, you can now no longer alter your models, because some migrations rely on the operation of the model at that "point in time" - if you create a model, with all its validations, field specifications, etc, and a migration uses that model. If you later try to change the model by adding or changing a validation, your migration will no longer work, as it is tightly bound to the old model. Is that bad enough for you? Being "decoupled" (separating things from each other, so that they're all free to change without breaking other things) is the fundamental principle of MVC - models do their thing, as do views, as do controllers - and it's made *deliberately* awkward to mix them up... because it's *bad*. So keep your migrations away from seed data, and also separate your tests from fixtures. Of course this assumes that you're not going back and editing migrations... but you wouldn't do that, because that's bad too! :-) -- 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.
