[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
on.
BTW, this may interest you (not sure):
http://svn.zope.org/Zope3/trunk/src/zope/app/versioncontrol/
See README.txt there.
_______________________________________________
For more information about ZODB, see the ZODB Wiki:
http://www.zope.org/Wikis/ZODB/
ZODB-Dev mailing list - ZODB-Dev@zope.org
http://mail.zope.org/mailman/listinfo/zodb-dev
