On Fri, 2006-04-28 at 02:53 +0000, [EMAIL PROTECTED] wrote: > 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 guess I may be remembering something we talked about earlier, but we were talking of tracking version numbers in the tables or something like that. That is where I have problems with using rollback as roll forwards to an older schema, because version numbers would incremement. Otherwise, everything you say makes sense (except we probably can prove the forwards and backwards will be the identity; I would hope we would try, at least). > 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? It is not my intention to put a halt to your ideas. They all seem sensible to me. I was just raising a warning that there are real situations where rollback cannot be interpreted as roll forwards to something equivalent. But, as I mentioned in the original email, this is handled today anyway by external procedures and in those (relatively rare) situations where it's required, it can continue to be handled that way. Focus on working out the schema evolution and making it work. The details will sort themselves out. There don't appear to be any real holes in your plan. :-) Cheers, Malcolm --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
