Tim Chase wrote:
> Back to the topic on hand, there are several ways to do > model-versioning. I'm partial to having a FooHistory table that > mirrors the parent table's fields but has a timestamp associated > with it. The most recent one is always the Foo object, but > before a Foo is saved, the current state is archived off to the > FooHistory table with the archiving timestamp. Yeah, I for one was put off django-reversion and other similar systems by their use of serialization/pickling and django generic relations, which mean they don't generate histories that are particularly easily queried later at the pure SQL/relational level (which is important for me, anyway) (django-reversion looks like it'd do what it says on the tin, don't get me wrong...) So just maintaining a history table was easiest for me. I confess I've been violating DRY to make them too - really I should consider making a Model subclass that inspects a main model and derives a reasonable history model definition for it, or something. Related, there's a book on approaches to dealing with time varying data in relational (or at least SQL) databases here: http://www.cs.arizona.edu/people/rts/tdbbook.pdf --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Django users" group. To post to this group, send email to [email protected] 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 -~----------~----~----~----~------~----~------~--~---
