Uros Trebec wrote: > 2.1. Basic models: > To enable history tracking Bob has to create a sub-class for those > models that he will like to track: > > class Post(models.Model): > author = models.CharField(maxlength=100) > title = models.CharField(maxlength=100) > content = models.TextField() > date = models.dateField() > > class History: > pass > > This works much like using Admin subclass. The difference is that if > the subclass is present then database will have change to include two > tables for this class: > > (the main table - not changed): > > CREATE TABLE app_post ( > "id" serial NOT NULL PRIMARY KEY, > "author" varchar(100) NOT NULL, > "title" varchar(100) NOT NULL, > "content" text NOT NULL, > "date" datestamp NOT NULL > ); > > > (and the history table): > > CREATE TABLE app_post_history ( > "id" serial NOT NULL PRIMARY KEY, > "change_date" datestamp NOT NULL, # required for datetime > revert > "parent_id" integer NOT NULL REFERENCES app_post (id), > "author" varchar(100) NOT NULL, # data from app_post > "title" varchar(100) NOT NULL, # data from app_post > "content" text NOT NULL, # data from app_post > "date" datestamp NOT NULL # data from app_post > ); > > I think this would be enough to be able to save "basic full" version of > changed record.
Although you have a date field in your example model it might not hurt to add an automatic timestamp to a model that uses versioning in this way. One that relies on a "data" field that could be changed by a user doesn't seem safe to me. I'd also like an automatic userid stamp on there over and above the "author" which again is a data field not a hidden system field. You might also consider some automatic "revision number" system which increments every time the record is changed. This makes it easier to "roll back" to the previous entry and can be a lifesaver if something happens to whatever is providing the dates. > 2.2. Selective models: > But what if Bob doesn't want to have every information in history (why > would someone like to keep an incomplete track of a record is beyond > me, but never mind)? Me either. Suggests that this may be a non-feature? I think the framework suggested is a great start. I would be interested in seeing a feature that tied changes not just to the user who made the change but also to the "session" that they made the change in. i.e. if my system allows "Dave" to have two active sessions at different computers I'd like to track what he did in each session not just what date the changes occurred. This is very helpful for user complaints and fraud detection. --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
