On Thu, 2006-04-27 at 20:23 +0000, [EMAIL PROTECTED] wrote: > Ok, thanks for clarifying on the comment on rollbacks. > > Still, I think rollbacks shouldn't be included. From the user's > perspecitive there won't be much difference between a rollback and an > evolve. In both cases they can write pre and post (or pre_rollback and > post_rollback) functions. Granted, they'll have to remember what their > models used to look like, but its not really up to us to make backups, > right? If a user really wants to rollback a production app, they can > get an old version of models.py out of their revision control and > evolve with it. If they're prototyping a new app and a change breaks > something, chances are they made a small mistake. Don't rollback - fix > the mistake and evolve forward. > > Its just not clear to me what we're gaining from rollbacks. On the > other hand, keeping track of all the shadows will clutter things up a > lot in the code and in either the filesystem or database (whereever > shadows end up living).
Coming from a background of using very large databases that evolve over time in high-availability, tightly controlled environments: the ability to rollback is very useful, because it matches the ability to roll back any other upgrades. You are proposing to implement rollback via "roll forwards to something we hope is equivalent", but in many production environments in large corporations, that isn't an acceptable risk. You need to be able to roll *back* to the earlier version and be able to prove (in some sense) that it is identical to the earlier version. This includes things like version numbers being the same as they were before the upgrade. Now, that being said, if Django didn't support this as part of schema evolution, the world will not end. In situations like the above, we would do what we do now (as you suggest), backup the schema before the upgrade and if we have to roll back work out a script to remove any extra data that is in the new columns and restore the schema to the backed up version. Such a procedure is often part of the rollout preparation. So we can document rollback as out of scope and suggest how to do it outside of Django, but there is a difference between rollback and evolve in an accountable production environment. Regards, 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 -~----------~----~----~----~------~----~------~--~---
