[ZODB-Dev] Non versioned objects

[Toby Dickenson]

On Thursday 01 Aug 2002 1:53 pm, Jim Fulton wrote:
> 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 di=
d,
> >> 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 n=
ot
> >> store previous versions for *all* objects.
> >
> > I dont think thats true. Undo isnt the only use for historical revisi=
ons.
> > 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 t=
his
> sort of auditing, you should provide a separate mechamism, possibly hoo=
ked
> up with ZODB in some fashion.

Yes, in most cases I agree with your principal. If the objects are comple=
x or=20
the changes frequent, then something implemented at application level is =
the=20
right way to go.

However, if your goal is to verify that there have been no changes to a s=
imple=20
object, and double-check a small number of changes, then doing it inside =
ZODB=20
seems to be the right way to go. For one, there are fewer things to valid=
ate.

I guess its similar to being able to set a file immutable flag in the ext=
2=20
filesystem.... Not very flexible, but powerful because of it.

> > 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?

Im not sure which question you are asking..... They cant support undo bec=
ause=20
they dont keep history. I dont want them to block undo because it would b=
e=20
annoying if they did (as you said... why keep any history for any object)=
=2E=20
The implementation of this property requires some magic in the storage=20
implementation.

This magic has similar implications to your solution of splitting the cat=
alog=20
into a seperate non-undoable storage; for example these magic objects cou=
ld=20
not have references to any other object [1] . However, other objects coul=
d=20
have references to a magic one. This is useful; a page could contain a hi=
t=20
counter attribute.

Im still not 100% convinced that this magic in the storage layer is bette=
r=20
than using different storages, and using the ZODB equivalent of symlinks.=
 It=20
would be an interesting experiment if there was a way to avoid serious=20
changes in higher layers.

> But really, transactional databases are, ultimately, poor choices for
> things like logs and hit counters. You really don't need, and don't wan=
t to
> pay the price for, transactional integrity.

Hmm, yes. The specific case I have in mind is a counter which is used to=20
derive billing information. I definitely dont want to count retried=20
transactions twice.=20


[1] why? because the creation of that reference would not be undone if th=
e=20
creation of the object was undone.