Why bother shuffling data between tables? I've got a wiki app I've been working on (slowly - hoping to release soon!), and I add a revision field ( IntegerField ), and just add a new entry with revision+1. The latest version has the latest revision number. Easy :-)
Then it's just a matter of something like this: page = Page.objects.all().filter( title="foo" ).order_by( '-revision' )[ : 1 ] Personally, I would add all the revision info (timestamp, username) to that same table as well. If you did feel the overwhelming urge to split it up, then I'd move the content field into a table by itself with a 1:1 relationship to the history table, for a few reasons - it's going to be a large amount of info, and lots of the times we don't want the content, but just a page/history list etc. Getting the content and ignoring it is a waste of database energy, to ignore this, we have to use Django's values( ) filter, but this de-objectifies things, and we lose stuff like get_absolute_url(). More importantly, in MySQL's MyISAM tables rows are read inline, so even if we don't SELECT content, MySQL's still reading it ( although maybe this is more of an argument for using InnoDB tables or postgres ). For deleting/locking/etc, it'd depend on whether a deletion/lock means ALL Pages with that title are deleted/locked ( here I'd use a status table which links a status to a title - i.e. all entries with title "foo" ), or whether the status change belongs to one page only - in which case, you may as well just add it to the main Page table. Cheers, Simon Waylan Limberg wrote: > I have been thinking about how to do something similar - specifically, > wikipage history. Note that I have not actually tried any of this yet > but I would split the history out into a second table. Perhaps this > incomplete example to illustrate: > > class Page(models.Model): > title = models.CharField(maxlength=30) > content = models.TextField() > status = models... > > class PageHistory(models.Model): > title = models.CharField(maxlength=30) > content = models.TextField() > page = models.ForeignKey(Page) > date = models.DateField() > comment = models.textField() > author = models.ForeignKey(User) > > Whenever a page is saved, the data in Page is overwritten and a new > record is added to PageHistory with the ForeignKey pointing back to > page. (Should PageHistory contain the current version of Page or only > previous versions? I'm not sure. The former feels more secure but the > later more DRY.) The only time PageHistory is accessed is if one needs > to review the history. I suppose this is a fancy form of logging. > > The problem I'm not sure how to address is if a Page is deleted. To > preserve the history, the records should stay in PageHistory, but if > the record is deleted from Page, then we leave a ForeignKey hanging. > Perhaps a status field should be altered on delete. Subclassing the > save() and delete() methods for Page should do the trick. > > In my case this only needs to be done for one model. Sounds like you > need to do this for every model which could get a little unweildy. I > don't know that I helped much. > > On 6/13/06, Paul Childs <[EMAIL PROTECTED]> wrote: > > > > I have been using Django for about a month now and I just moved over to > > the development version. > > > > I am creating an application in which the client has dictated very > > stringent database record management in order to have a detailed audit > > trail on all changes made data. This does not necessarily mean logging. > > > > The rules are quite simple. > > > > · once saved, records are immutable. > > · records can not be deleted. they must be marked for deletion only. > > · to "edit" a record a new record is created with the new changes > > and a reference must point back to the old record > > · a comment must be attached to every edit or delete to explain why > > the action was taken. > > > > I was planning on doing this with a combination of Managers, Views and > > overriding the delete() and save() methods of my models. I have done > > some experimentation and found this to be awkward, not very elegant and > > to contravention of the DRY principle. > > > > Is there a better way of achieving this or am I on the right track? > > > > > > > > > > > > -- > ---- > Waylan Limberg > [EMAIL PROTECTED] --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
