Changes between Version 3 and Version 4 of FullHistory


Ignore:
Timestamp:
Jul 16, 2006, 3:58:02 AM (18 years ago)
Author:
jim-django@…
Comment:

note about time-oriented databases

Legend:

Unmodified
Added
Removed
Modified

  • FullHistory

    v3 v4  
    1010You can grab the current code from the "full-history" branch:
    1111{{{
    12 svn co http://code.djangoproject.com/svn/django/branches/full-history/
     12svn co http://code.djangoproject.com/svn/django/branches/full-history/
    1313}}}
    1414
    … …  
    3535#!python
    3636class Post(models.Model):
    37     author = models.CharField(maxlength=100)
    38     title = models.CharField(maxlength=100)
    39     content = models.TextField()
    40     date = models.dateField()
     37    author = models.CharField(maxlength=100)
     38    title = models.CharField(maxlength=100)
     39    content = models.TextField()
     40    date = models.dateField()
    4141
    42     class History:
    43         pass
     42    class History:
     43        pass
    4444}}}
    4545
    46 When this is done every "Post" object will be saved to a "appname_history" table when created, changed or deleted. 
     46When this is done every "Post" object will be saved to a "appname_history" table when created, changed or deleted. 
    4747
    4848=== API ===
    … …  
    7878poll1 = poll1.revisions.revert_to(id=222)
    7979}}}
     80
     81
     82=== Discussion ===
     83
     84The ability to keep previous states of a table accessible is well described in Richard T. Snodgrass's (http://www.cs.arizona.edu/~rts/) "Developing Time-Oriented Database Applications in SQL" (http://www.cs.arizona.edu/people/rts/tdbbook.pdf). Adding the ability to designate a particular model as a transaction-time state table, with suitable methods added to the model's API, and with all queries defaulting to using either the current time or the latest time.
Back to Top