I have an idea that should simplify migrations problems.
Suppose I make a migration that get distributed on many servers, then I notice it is wrong.
It should not run, but it may have already ran. Then I want it to stop this error.
The recommended way to handle this situation is not easy, so I have 2 options:
The 1, has a problem, if it destroys data or if it causes errors, problems will arise (given that the migration will run)
The option 2 has the problem of being difficult and error prone.
So I think why not to mark the migration as bad.
def bad?; true; end
When ruby notice a bad migration has run it ask to rollback (on db:migrate) and if it has not it should skip it.
I'm not sure that this should be supported as it seems like a relatively complex edge case.
Why don't you just rewrite the up to be inert and print a warning?
Migrations are suposed to not be rewrited.
If rewrited the up to be inert and print a warning, then there will be a diference across machines (in some of them it has run with content and others have run without), so, in some of them the down method will work and the other will not. Then the difference have to be corrected manualy.
Migrations are suposed to ease the handling of problems (like diferences across machines), the down method is missused in the current working of migrations, because they are only used in development machines when not commited on git.
This feature will enhance migrations usefullness for helping in this complex edge cases, also will ease rolling back migrations commited (witch is a more common situation), and will not add any hassle in not problems environment.
May be, because I'm a beginer with rails bad migrations result in a problem, and I should learn the 'correct way' (I should), but I think I'm not the only beginer and this will make simplier to start with rails (commited bad migrations are a common beginer problem).
Feature requests without code are best posted to rails-core. Since this is months old with no real discussion, I'm closing.