Record hash of applied migrations

[thomasf@…]

Simple list spec:

• After an migration has been applied its hash is stored in the migration table
• The hash value could probably just be a file hash of the migration python source file
• Before new migrations are applied all previous migrations should be checked to not only have the correct id but also the same content.
• Migration modification without triggering any hash errors (like documentation only updates) can be supported using a hash property on the migration model that allows the developer to let the migration keep its previous hash.
• An --force-update-migration-hash option can be added the migration command for an explicit "i don't care' situation.

I've seen this other database migration frameworks and it has been a very useful thing to have at times.

[Andrew Godwin]

I'm going to make a call on this as WONTFIX - while it's a nice idea, in practice I've seen good reasons to edit old migration files (adding comments, re-whitespacing) and things like git might automatically change the hash of all the files if their line ending mode is changed.

In particular, it adds a non-obvious failure mode for people who won't be immediately familiar with what's going on, especially if they just popped back in to add some comments or something, and the only thing Django can do is be very user-unfriendly and moan; what would we propose the user do? Roll back everything and re-apply it?

I can see some merit in perhaps doing some sort of hash off of the Operations themselves, thus hashing only the semantic meaning of the migration, but that would be a relatively large change and not something I'm prepared to introduce in 1.7, especially as it puts even more onus on people already having to adapt to this big change. Perhaps we can revisit it for a later release, but since I'm not going to mark it as accepted I can't leave it languishing in "new", so I feel closing is cleanest for now.

[anonymous]

Good call on closing the issue.
Thanks for replying.