Menu
I'm using Rails 3.2 and have a migration that contains the code:
add_column :users, :gift_aid, :integer, :default => 2 # reset columns User.reset_column_information ... code here to load legacy data from sqlite3 database ... # now create a user with the loaded column data user = User.create( ...other cols..., :gift_aid => migrated_gift_aid_column_data, ...other cols... ) and I get unknown attribute: gift_aid when running the migration. User.column_names shows the same list before and after the call to reset_column_information.
Oddly when I manually drop the column in mysql and re-run the migration it works as expected. Starting from the first migration again with an empty database and it doesn't work so it's something to do with running all the migrations rather than the single one.
I have a couple of previous migrations on User model, both include reset_column_information and both work fine.
I'm really scratching my head on this one - anyone got any ideas
524
You must rollback the migration (for example with bin/rails db:rollback ), edit your migration, and then run bin/rails db:migrate to run the corrected version.
If you need a bash one-liner to determine whether to run a migration or not (e.g., only migrate in a Heroku release phase command when there is a pending migration), this works: (rails db:migrate:status | grep "^\s*down") && rails db:migrate || echo "No pending migrations found."
If you have already run the migration then you cannot just edit the migration and run the migration again: Rails thinks it has already run the migration and so will do nothing when you run rake db:migrate.
I think this must be some kind of bug related to schema caching... this might work:
User.connection.schema_cache.clear! User.reset_column_information (for Rails 3.2.2)
158
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With
