> I don't what changed from Rails 2.1.2 and 2.3.4 to break these > migrations. If anyone's encountered this issue or can shed some light > on the problem it would give me some peace of mind. > > I worked around the problem by dynamically creating and destroying > classes to access the state table each time I need them, but I'd much > rather understand the root cause of the problem and fix it if needed. >
The core issue is that the right way to do this is to do class SomeMigration < ActiveRecord::Migration class State < ActiveRecord::Base end end Like that each migration has its own copy of the class, no interfering. The big difference between 2.1.2 and later versions is probably that by default in production modes all classes are loaded up front, so in migrations 2 & 3 you are not creating a new state class - you're reopening the application's state class which could easily have validations, callbacks etc. and be confused by the fact that the columns aren't as expected. Last but not least, running all the migrations from the first to the last is not the reccomended way to deploy an app - you should be loading the schema file. Fred --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
