[Arthur Peters]
> Thanks you very much.

Hey, we're both named Peters -- you're probably the son I never knew (or
vice versa ;-))

> I'm still having issues but I'll investigant it myself before I ask
> anything else. I think I came across as pushy and demanding and I'm
> sorry. I didn't mean to. I just ment this as questions and ideas.

Hmm.  I must have said something that came across as being annoyed.  That
wasn't the intent -- really.  You came across as ... optimistic <wink>.
There's nothing wrong with that, and discussion is very welcome here.

> You know ZODB much better than I

Some parts, but I really know very little about the undo implementation.  I
wasn't involved in coding it, and AFAIK there are no docs that explain how
to use it.  In fact, I'm not even sure the sample code I sent shows the
_intended_ way to use it.  But by posting my best guess on this list, I hope
that if someone knows better, they'll yell at me for what I did, and we'll
all learn from that.

> and I'll go for a app-level implementation of undo unless I happen
> across a nice way to use ZODB for it.

That's my best recommendation.  Database undo is a dicey feature, even in
theory when it's not strictly stack-like.  For example, transaction 1 makes
a change to object A.  Transaction 2 makes a change to object B based on
state it sees in object A from transaction 1.  Transaction 1 alone is
undone.  Oops!  Object B is left with state that doesn't make sense anymore.
It's exceedingly easy to violate application-level cross-object invariants
this way.  Couple with that all storages eventually have to throw
non-current object revisions away, and there's not much left you can rely

BTW, this may interest you (not sure):


See README.txt there.

For more information about ZODB, see the ZODB Wiki:

ZODB-Dev mailing list  -  ZODB-Dev@zope.org

Reply via email to