[Zope] Zope Persistence (was: XML-RPC within ZOPE)

[Jan-Ole Esleben]

> > That ZOPE raises an error is fine. That I _might_ run into such
> > situations with other tools is true.
> You *will* run into these problems in exactly the same cases in any other tool.

I'm sorry, but that's just wrong, and I have given examples of such
situations. To simplify, in ZOPE, for any given product, during a
transaction the product is effectively locked. So if I have, say, a
list field that contains some data and a dictionary field that
contains some other data, and the "internal" call changes the dict
while the original call changes the list, that breaks the transaction,
while in usual situation in a database, nothing would break.

> > But in ZOPE, it is definitely the
> > case that data and program are coupled in an implicit way that makes
> > these cases much harder to debug and avoid, because if the two methods
> > in my example operate on different sets of data, which they probably
> > would, or if one of them did a read before calling the external method
> > and then afterwards a write (on an SQL database maybe), nothing would
> > happen if I used explicit data storage!
> It will not happen i Zope in this case either.

No. It does happen, and it _did_ happen in my original problem. Zope
doesn't even care if anything actually changes, it just considers an
object changed that set self._p_changed=1.

> > In Zope, it's just the whole object that's tainted.
> You just said "different sets of data". That reasonably must mean
> different objects, unless you envision having huge objects with only
> marginally connected sets of data all stored as attributes. And then
> you have other problems. :-)

No. An object usually binds together different sets of data (as in the
above example - it has several fields, and that is true for almost any
given object). What you are saying is "don't program the ZOPE way",
and it would eventually lead to the conclusion that your product
classes should not have any persistent data, which is the conclusion I
have come to.

> > That's my whole point. I think it is a very
> > significant point nonetheless, because this is just an extreme case of
> > what happens when you couple data and programs, and persistent classes
> > are just that: application data inside program code.
> Eh, no they aren't.

Please don't just claim stuff. ZOPE has persistent classes. Persistent
classes store data that in ordinary programs would not survive as
long. In ordinary systems, you would have to find a way to store the
data and retrieve it, thus having a model that isn't implicit and
entangled with your code. Of course, you could do the same in ZOPE,
but I addressed that above, and you could mess up ordinary code, but I
think we're agreed that it is not something you should aim for (and I
think I have made it clear why I do not believe it's as easy to mess
up generic Python code in this way).

Ole