The rollbacks are really only usefull (in my mind) for when you go forward on an app, and it turns out to break something, so you "rollback". I do think it is a bit of a fringe-case, and can be handled by proper database backing up. However, I don't see why we couldn't support it. Plus, I've figured out that we're going to have to keep a record of the models anyway.
On 4/27/06, [EMAIL PROTECTED] <[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). > > Joe > > > > > --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
