This project is archived and is in readonly mode.
Add magic encoding comment to generated files
Subject: [PATCH] Add column_exists and index_exists methods for use in migrations.
Sometimes databases are tinkered with, and then a migration is written to do things the right way. At this point though, if you're writing a migration to add a column and its already in the table, you need to do some manual work to figure out if it already exists (same goes for an index). So, I've wrapped up that logic in a couple helper methods, which should make it even easier to write less brittle migrations.
-
Pratik- Milestone cleared.
- Assigned user set to Michael Koziarski
-
Jordi BunsterI don't get this. Why would one conditionally create things in migrations?
Doesn't each one run over a consistent state?
-
jack dempsey (jackdempsey)Jordi,
I thought the comment I left originally would clarify things. Specifically, I had a situation where I had to quickly add a column to a table in a production system. Later on when I had a chance, I wrote the proper migration for this. I didn't want to drop the table in production, and break things, and then run the migration, so adding some logic like this to the migration takes care of that situation.
So yeah, sometimes the state isn't consistent...and in general, given that things go poorly if the column/index already exists, I think something like this is helpful for making those strange situations easier to deal with.
-
Michael Koziarski- State changed from new to wontfix
I agree with Jordi on second thoughts. We should focus on encouraging users to follow the 'right' path with migrations.
To handle the case where it's already been manually applied in production I think we should perhaps have a rake task which lets you 'fake apply' a particular migration
-
jack dempsey (jackdempsey)
Koz,
While you might want to encourage users to keep things perfect, reality does not work that way. I don't like the idea of a 'fake apply' migration...I'm not even sure what that means...Given that this really doesn't hurt anyone, and helps those trying to fix a particular need, I'm not sure I understand the wontfix. Its not like it adds a huge amount of bloat.
If you think this would be better served in a plugin, cool, lemme know. But just denying this seems a bit shortsighted with how things happen in the real world.
-
jromAdding this kind of syntaxis to the migrations would make things ugly... And really not very useful. If you manually touch the DB, just update the schema_info field and skip that particular migration...
-
jack dempsey (jackdempsey)
I'm certainly not tied to the syntax. IRT manually tweaking what's run, what if you don't know or don't have access? Maybe there's more that needs to happen in the migration?
I think I'll just create a plugin. I can imagine wanting other helper methods and it sounds like they'll have similar criticsm, so, easier to just keep them separate.
-
Michael Koziarski
In cases where the migration consists of multiple steps, only one of which has been run. Then you can split it into several steps (after all, they haven't been run in production yet).
I'm not opposed to adding these helpers, it's more that I feel we need a better reason to make this available. table_exists? is only there because of an implementation detail for supporting AR::Base.inspect. How would we document this in a way that doesn't say "it's expected that you'll manually run things and also run migrations"
-
-
Jeff Kreeftmeijer
Automatic cleanup of spam.
-
Jeff Kreeftmeijer
Automatic cleanup of spam.
-
Jeff Kreeftmeijer
Automatic cleanup of spam.
-
-