Quoting Jeffrey L. Taylor <[email protected]>: > Quoting Thufir <[email protected]>: > > > > > > On Nov 21, 2:48 am, "Jeffrey L. Taylor" <[email protected]> wrote: > > > Quoting Thufir <[email protected]>: > > > > > > > Why does this migration fail? Using seed_fu was suggested, which I > > > > don't > > > > mind, as it looks quite convenient, but I'm scratching my head over the > > > > error: > > > > > > Fromhttp://rails.rubyonrails.org/ > > > > > > reset_column_information() > > > > > > Resets all the cached information about columns, which will cause them to > > > be reloaded on the next request. > > [...] > > > > Which I'll try, but *why* would it fail, given that the table > > information has been deleted with the "rake VERSION=0" command, which > > dropped the table? There's no table info cached, is there? If so, > > where? > > > > The table information has been deleted from the database and the schema > changed, the table classes need to be recreated from the new DB schema. Rails > does not try and modify the model class to to match the new schema, it just > re-creates when you signal that you are done modifying the schema AND that you > want to use the new schema/model. > > So the short answer is, contrary to your expectation of how Rails works, the > DB info is effectively cached in the model class's existence. >
If you separated the migration and the population with seed data into two migrations, the reset_column_info call would not be needed. Jeffrey -- 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=.
