Menu
I'm attempting to write my own timestamps method that gets run during the migration. The one that is in place now adds a NOT_NULL constraint on the field, and I really really don't want that.
The problem I have is that I have a multi schema'd database. Where each major client gets their own schema. When we on-board a new client we create a new tenant record then run a migration for a newly minted schema.
The new schema is supposed to be an exact copy of the tables in the other schemas, except of course with no data.
The last migration I ran was using a slightly older version of rails. Still in the 3's but a smidge older. When it created the timestamps they were NULLable. When I ran migration the other day (on a new rails)... Well all the fields are now NOT_NULL
I have code that was developed with the idea that updated_at was only populated when the record was updated... not when it was created. (third party apps and database "functions" create the records).. The third party apps and database functions that create records are falling down on the new schema... I've gone in and removed all the NOT_NULL constraints on all the tables manually, but I don't want to have to write the cleanup right into my migration task, so that all future tables are corrected..
I figured the best thing to do was to override the timestamps method that was changed, back to one that didn't break existing code.
So there's the reason I need to revert/override..
My question now is... How do I override the method. I can't see a clear class path to it and I'm not exactly sure how to override it..
332
just use rake db:reset , that will drop your database (same as undoing all migrations) and reset to the last schema. UPDATE: a more correct approach will be using rake db:migrate:reset . That will drop the database, create it again and run all the migrations, instead of resetting to the latest schema.
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.
To check for status, run rails db:migrate:status . Then you'll have a good view of the migrations you want to remove. Then, run rails db:rollback to revert the changes one by one.
Every time a migration is generated using the rails g migration command, Rails generates the migration file with a unique timestamp. The timestamp is in the format YYYYMMDDHHMMSS . Whenever a migration is run, Rails inserts the migration timestamp into an internal table schema_migrations .
Put this in a monkey patch... Easy as!
class ActiveRecord::ConnectionAdapters::PostgreSQLAdapter::TableDefinition
def timestamps(*args)
options = args.extract_options!
column(:created_at, :datetime, options)
column(:updated_at, :datetime, options)
end
end
As Maniek said. Updates to rails will be ignored because of this "fix".
But his initial offering does the same. Also to accommodate his fix, you'd need to go back through ol' migrations and replace "timestamps" with the new code. Add to that that you'd have to replace all future auto-generated migration too.
I don't think that fits well with DRY.. Nor does it fit in SPOT.
Just B carefulllll!
75
what's wrong with:
create_table :foo do |t|
t.text :bar
t.datetime :created_at
t.datetime :updated_at
end
?
1
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
