Hi Brett, Data loading via db/seeds.rb (and it's accompanying rake task) is a better practice, but I do agree with Ben that sometimes you just end up accessing models in your migrations. I solve that by adding the model definition to the migration namespace and making sure that I'm always using the scoped version.
Rob On Mon, Oct 17, 2011 at 11:23, Brett Stewart <[email protected]>wrote: > Thanks for the good advice Ben, > > I've removed migration containing load data and put that code into load > scripts. Lesson learned. > > Brett > > > On Mon 17 Oct 2011 10:18:39 AM PDT, Ben Hughes wrote: > >> Although everyone breaks this rule, it's generally bad practice to use >> model references in your migration files, precisely because of the problem >> you're now running into. Migrations are supposed to affect *schema*, and you >> don't want schema cross-dependent on your models and the state of those >> models in your source code. You want your migrations to always be idempotent >> given a particular schema revision. So for example if you really want to >> update data in a migration (leaving aside whether this is good practice or >> not - that's a separate debate): >> >> The wrong way: >> >> Customer.update_all :field => 1 >> >> (A) right way: >> >> ActiveRecord::Base.connection.**execute("UPDATE customers SET field = 1") >> >> Assuming you don't actually want to change the semantics of your migration >> scripts, what I would probably do is modify the migration to not depend on >> that model and instead directly operate on the schema. But then again >> depending on what you're doing it might make more sense to extract this >> stuff out as seed data or some other loader anyways, but that's hard to >> judge without knowing the specific circumstances. >> >> Another option instead of (3) is to define a stub ActiveRecord model >> *within* your migration file, so it's in scope only for your migration. See >> the example here: >> http://ketan.padegaonkar.name/**2010/11/20/using-models-in-** >> rails-migrations.html<http://ketan.padegaonkar.name/2010/11/20/using-models-in-rails-migrations.html> >> >> Ben >> >> >> On Mon, Oct 17, 2011 at 10:08 AM, Brett Stewart < >> [email protected] >> <mailto:brett.c.stewart@gmail.**com<[email protected]>>> >> wrote: >> >> I have a situation where I've renamed a table and removed a model >> after >> many migrations. In prior migrations, the model is used to save >> default >> data to db. I have a new developer who want to run migrations for the >> first time, but now an error occurs because the model which sets the >> data has been removed from the source. >> >> The list of options I've thought of: >> >> 1) give SQL dump of db so he can start from current state >> >> 2) Remove migrations which set data and place into a script (and >> Capistrano recipe) >> >> 3) Add model back to source, and deprecate (starting to smell bad) >> Question: What is the best method for adding a deprecation warning >> on an entire model and not just it's methods? >> >> I'm tempted to use the following >> ---- >> >> require 'active_support/deprecation' >> >> class B< ActiveRecord::Base >> def initialize(attributes = nil) >> self >> end >> deprecate :initialize >> end >> ---- >> >> This probably won't work because of addition of validations after >> future migrations >> >> 4) modify migrations (smells really bad) >> The system has not been put into production yet, but this is not a >> maintainable solution. >> >> >> Thanks in advance for help, >> >> Brett >> >> -- SD Ruby mailing list >> [email protected] >> <mailto:sdruby@googlegroups.**com<[email protected]> >> > >> >> http://groups.google.com/__**group/sdruby<http://groups.google.com/__group/sdruby> >> >> >> <http://groups.google.com/**group/sdruby<http://groups.google.com/group/sdruby> >> > >> >> >> -- >> SD Ruby mailing list >> [email protected] >> http://groups.google.com/**group/sdruby<http://groups.google.com/group/sdruby> >> > > -- > SD Ruby mailing list > [email protected] > http://groups.google.com/**group/sdruby<http://groups.google.com/group/sdruby> > -- SD Ruby mailing list [email protected] http://groups.google.com/group/sdruby
