Migration solution - PAIN to write, but compatibile by default

gistfile1.md

"Write safe migrations" approach.

This is what I've mentioned on our call. Let me prove this could work and please prove me wrong or point weak spots.

Assumptions

• We can agree on how many steps we want to be able to rollback to (capistrano supports it, now on webstore is 2. I think increasing this too much makes no sense. Personally I think 2 is perfect - can't imagine that we release 1.19, after two weekes we release 1.20, after another 2 weeks 1.21 and at this point PO decides we want to rollback to version from a month ago).
• don't think that database migrations is about just database migrations - it's also about writing code in a way it can handle this migrations.
• future actions can be easily managed with something similar to roadsigns. For migrations, in case you need column to be removed in some unspecified future you can leave file CHECK_THIS_BEFORE_MAKING_NEW_MIGRATION, with entry 2015-01-12 prepared for column foo removal. Please remove after at least 5 releases (see first assumption)

#Solution I'll go through each scenario in https://github.com/NexwayGroup/N3/issues/2402

1.1 Add column

Easy - in case of rollback this column can stay as it was. Just one assumption here migration should check if the column exists first.

1.2 Column remove

Q: does it really have to be handled? It's by nature - not reversible operation. There's rarely a case that column have to be deleted in order for new feature to work. My suggestion would be: write an accessor on a model (VarienObject getFoo() and getData('foo'), also set*`) to issue exception in developer mode, and loge deprecated warning on production.

So - don't remove immediatelly - set up conditions for future removal.

##1.3 column rename instead of renaming foo to bar add column bar, and copy all data from foo. Also implement your change in code, that every time bar is set (setBar(), setData('bar')) - it's mirrored in Foo. Set up flag for future removal (see assumptions)

2 Table operations

Actually same rules could apply as for columns. Can't see much difference here.

3. Data operations

This is the most tricky part, I may tackle this later...

Feel free to fork it and improbe, comment and don't have mercy for anything what's will not work.