[ZODB-Dev] Non versioned objects

[Jim Fulton]

Toby Dickenson wrote:
> On Wednesday 31 Jul 2002 6:15 pm, Jim Fulton wrote:
> 
> 
>>If, in a transaction, you didn't store previous versions for some objects,
>>then you couldn't undo that transaction, because, if you did, you'd
>>undo to an inconsistent state. So, if, for a transaction, you didn't store
>>previous versions for some objects, you might as well not store previous
>>versions for *all* objects.
>>
> 
> I dont think thats true. Undo isnt the only use for historical revisions. I 
> think its reasonable to want to keep a long history of certian important 
> objects for auditing purposes, even though you cant 'undo' back to those very 
> old revisions. For certain objects that shouldnt change much, I would like to 
> record all history since creation.

We'vb thought about this sort of application a lot, however,
we've come to terms with the fact that although ZODB is a pretty good database,
it's a bad version control and auditing system. If you want this sort of auditing,
you should provide a separate mechamism, possibly hooked up with ZODB in some fashion.

> Of secondary importance, I can see a use for objects such as page hit counters 
> which keep no history but do not block undo. This just a fine-grained 
> object-level alternative to your solution:

Why wouldn't they block undo?  But, chances are, page hit counters would occur in
otherwise-read transactions.

But really, transactional databases are, ultimately, poor choices for things like
logs and hit counters. You really don't need, and don't want to pay the price for,
transactional integrity. Further, you probably don't want to do this sort of thing in
the app server if you are doing any caching. You want to collect this data in the cache,
to get realistic data.

Jim

-- 
Jim Fulton           mailto:jim@zope.com       Python Powered!
CTO                  (888) 344-4332            http://www.python.org
Zope Corporation     http://www.zope.com       http://www.zope.org