My hope is that it won't be 'roll forwards to something we hope is equivalent' because the user would be using evolve with the old version of their schema, hopefully from their revision control. If you're using the exact same schema as you were before you rolled out the upgrade than you're rolling forwards to something you know is equivalent. I suppose you don't know with certainty that the path taken to get from one version of your schema to the next and then back again will be identical. But you do know that whenever you evolve, you end up with tables in the database that exactly match the schema you're evolving to. It will remain the admin's responsibility to make sure their data migrates safely. Either you have to write pre_rollback and post_rollback functions to migrate your data or you have to write pre and post functions.
I suppose when rolling forward to the old version, evolve might not realize that a particular field should be altered. In other words, it might delete one field and create another rather than altering the existing field. Keeping an exact record of how things were upgraded would allow you to undo exactly what was done. This could prevent some data lossage. But exactly the same thing (a field getting deleted when it should get altered) could happen when you're upgrading, and if that happens it doesn't do you any good to be able to roll back in exactly the same way as you rolled out. I don't think there is a way to prevent the possibility of losing your data. So, it seems crazy to roll out changes without backups. The way I envision things happening is, if you want to rollback your schema along with other upgrades you would just rollback to an older version of your revision control system, which would roll back the schema and the upgrades that came along with it. Then all you have to do is write pre and post and evolve your schema. What I think evolve should do is guarentee you that the schema you have in models.py is exactly the schema in the database, and provide function hooks to allow you to write migration code. Of course, you guys are all a lot more experienced with large corporations and the risks they're willing to take. If this is unrealistic just let me know. Also, Brant said something along the lines that we would have to keep track of all the versions anyway - why is that? --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Django developers" group. To post to this group, send email to django-developers@googlegroups.com To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/django-developers -~----------~----~----~----~------~----~------~--~---
