That is exactly what i did for a project :)
When you register a model for versioning, automagicly a new model is created which the original model + an 'version-control' abstract base model to add things like version numbers, datetimestamps, methods to diff between versions etc. Also all unique restricted are removed from the 'history' model to not create constraints problems. So you can stuff like: FooHistory.objects.get(rev=42) FooHistory.objects.latest().diff(fooInstance) FooHistory.objects.latest().revert() Ofcourse now you need to migrate two tables instead of one, on a schema change, but in most cases that's just repeating the migration. This approach has worked very well for me. Though i havn't used it any 'big' projects. Bas On Fri, 3 Oct 2008 17:29:34 +0300, Erik Allik <[EMAIL PROTECTED]> wrote: > > What if, for each model under version control, you'd create an > identical table (except the ID field would be a foreign key, not a > primary one). Any time a migration is run on that model, the same > migration could be run on the "twin" table, too. > > Erik > > On 02.10.2008, at 18:34, David Hall wrote: > >> >> That is a problem, to be sure, and I'm not sure if a reasonable >> solution >> exists. >> >> As it stands, Django is currently lacking an automated rollback/ >> recovery >> for models. The fullhistory branch tried to address this lack, but >> seems to have been abandoned for the time being. >> >> django-reversions implements this rollback/recovery facility in a way >> that aims to be easy to integrate with existing projects. It improves >> upon the current fullhistory implementation by: >> >> - Using the serialization framework instead of pickle. >> - Allowing groups of changes to be grouped into revisions. >> - Integration with newforms-admin. >> >> Changes to database schemas will indeed break the rollback facility. >> Given the mind-boggling vastness of possible schema migrations, I >> honestly would not know how to begin to implement such a feature! >> >> Nevertheless, I hope that django-reversions remains a useful tool. >> >> David. >> >> Bas van Oostveen wrote: >>> But your schema's will most likely change over time. And sometimes in >>> significant ways which do not have a likely default; e.g. splitting a >>> full_name field into a first_name and last_name field or visa-versa. >>> >>> Now after applying this change to the database, how will >>> django-reversions work when you want to undo and go back to an >>> earlier >>> version of a record in this table ? (which didn't have this change) >>> >>> The fields in the database/model now do not match against the >>> serialized >>> copy right ? >>> >>> Bas >>> >>> >>> On Wed, 2008-10-01 at 16:52 +0100, David Hall wrote: >>>> This discussion has been moved from django-developers. >>>> >>>> To answer a pending question: This application is for tracking >>>> versions >>>> of data, not performing database schema migrations. Thus: >>>> >>>> - django-evolution concerns itself with maintaining versions of >>>> database schemas. >>>> >>>> - django-reversion deals with maintaining versions of the model >>>> data. >>>> >>>> It does not integrate with subversion. Instead, it uses the django >>>> serialization framework to store serialized models in a special >>>> database >>>> table. >>>> >>>> David. >>>> >>>> David Hall wrote: >>>>> I've just released an open-source version control application for >>>>> Django. It is available for download from Google code. >>>>> >>>>> http://code.google.com/p/django-reversion/ >>>>> >>>>> Features include: >>>>> >>>>> - Roll back to any point in a model's history - an unlimited undo >>>>> facility! >>>>> - Recover deleted models - never lose data again! >>>>> - Admin integration for maximum usability. >>>>> - Group related changes into revisions that can be rolled back >>>>> in a >>>>> single transaction. >>>>> - Automatically save a new version whenever your model changes >>>>> using >>>>> Django's flexible signalling framework. >>>>> - Automate your revision management with easy-to-use middleware. >>>>> >>>>> It can be easily added to your existing Django project with an >>>>> absolute minimum of code changes. >>>>> >>>>> It's so far been previewed by a half dozen developers, with good >>>>> feedback. I'd appreciate any comments / suggestions you may have >>>>> to >>>>> offer. >>>>> >>> >>> >>>> >> >> -- >> David Hall >> Technical Lead >> Etianen.com >> Tel: 07896 106290 >> >> Email [EMAIL PROTECTED] >> Web www.etianen.com >> ------------------------------------------------------------------- >> Ask for help at [EMAIL PROTECTED] >> Etianen.com is a small, professional web development agency that >> specialises in fast-paced, creative development. >> ----------------- enlightened website development ----------------- >> >> > > > > --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to django-users@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-users?hl=en -~----------~----~----~----~------~----~------~--~---