> One way the developer can deal with this (what I've been muddling through in a > tough spot in my case, in fact) is to do things like: > > def self.up > # ... > ActiveRecord::Base.connection.select_all(...).each do |foo| > execute "insert into bar (...) values (...)" > end > > Blech. > > But, this doesn't catch everything (the before_save example is unhelped, > e.g.). > Ultimately, the developer can't (and shouldn't have to) predict what the > future > is going to bring, and shouldn't have to code around this sort of problem.
RIck, I've been running into this with Mephisto, a little blogging app I've been writing on the side. After a pretty intense weekend of hacking, I found myself doing a lot of db restructuring. Obviously, the earlier migrations weren't working, because the model and or table has been renamed. To work around this, I just started creating temporary models per migration. I find that much nicer than reverting to ActiveRecord::Base.connection for my delicate sql needs. It might be best to create the temporary model classes inside the migration class to keep them from clashing. This temp model gives me a nicer way to manage the data, and frees me from worrying about filters, validations, changing method names, etc. I may throw together some task that takes my initial schema and runs through all the migrations eventually. I think this kind ability is important for packaged apps, so I'll certainly share any progress I make in Mephisto. Take a look: http://techno-weenie.net/svn/projects/mephisto/trunk/db/migrate/ -- Rick Olson http://techno-weenie.net _______________________________________________ Rails-core mailing list Rails-core@lists.rubyonrails.org http://lists.rubyonrails.org/mailman/listinfo/rails-core
