Hi Joe. "devolving" or performing a "rollback" on an evolution is covered only slightly at the end of my proposal. Basically the idea would be to also add "pre_rollback" and "post_rollback" function hooks for the evolve() function as well. This way, the responsible admin would be able to provide rollbacks whenever needed. But we can't problem ourselves with the possible loss of data. That's just going to be there. We can minimize, but I think the best option is to suggest backing up of the database to the user.
On 4/26/06, [EMAIL PROTECTED] <[EMAIL PROTECTED]> wrote: > > Hi all, I'm a CS undergrad at the University of Minnesota. I hope to do > a Summer of Code project with Django. Specifically I'd like to work on > schema evolution. I just wanted to introduce myself and get involved in > the process. > > So enough with the introductions. On to my comments on the proposal: > > I like the per app versioning. I think that per model versioning could > easily get ugly. Keeping track of the relationships between models with > different version numbers would not be any fun. Also, expressing the > evolution at the app level allows evolve to create new models (as in > the blog example of adding a tags model). Also, per app versioning > keeps the version numbers of related models in sync. If we had per > model versioning then we might have an up to date tags model at version > 2 and an up to date entries model at version 3. That feels wrong. Since > the models are related to each other, if they're both up to date it > makes sense for them to have identical version numbers. > > I wonder if we want to support 'devolving' (going back to old > versions). I think devolving should be treated exactly the same as > evolving - you actually never go back to old versions, you just evolve > your models so that they are the same as they used to be. Having some > special mechanism that would automagically devolve models would either > cause lossage or be rather messy. > > For example evolving might remove a field from a model. Devloving > should recreate the field, but what about the data that the model used > to have in that field? The user probably wants their data back, but I > don't think there's a good way to automagically recreate the data short > of keeping track of all the schemas that have ever existed and all the > data that's ever been in the model. So trying to make devolving more > automatic than evolving either means a big mess of tables of data that > used to exist or a large potential for lossage. Still, it feels like > there is a better way to deal with devolving. Since we already have an > explanation of how to evolve it feels like we ought to be able to > automatically figure out how to devolve. > > 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 -~----------~----~----~----~------~----~------~--~---
