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

[Jan-Ole Esleben]

> Little bit tricky to try out as testers need to guess what all the
> missing code is.

Any standard persistent ZOPE product wrapped around this will do.
These are the only methods in a ZOPE product that inherits from Item,
Persistent, RoleManager and Implicit.

> Also, for this kind of code demonstration, rather
> than directions for commenting/uncommenting and relying on the tester
> to restart the server between trails, provide different methods or
> even different classes.

If I did that, people would say "somethings wrong with your testing"
and they would have to do a line-by-line comparison and still have
room to doubt my statement.

> But there is no extra transactional framework for XML-RPC clients
> (which your example has). Or for that matter acting as an XML-RPC
> server nested within some external transaction (which your example
> has).

I was initially talking about a more complex situation that has been
gradually simplified. ZOPE should be able to act as an XML-RPC client
to the outside world.

As to me not understanding what you all are saying: I believe I
understand, I know that theoretically - from a merely "technical"
viewpoint, it works, I just look at it from a different angle. Of
course you have to know a framework and its limitations, but this
error I stumbled upon strikes me as really complex (even though you
keep repeating it's very simple if you just acknowledge xyz), for
instance because the docs "aren't perfect" and say that
"You must explicitly signal any changes made to mutable attributes
(such as instances, lists, and dictionaries) or use persistent
versions of mutable objects, like ZODB.PersistentMapping (see below
for more information on PersistentMapping.)" - the _first_ option
being mutable attributes! Also, there is no "below".
I believe you when you say that it is really very simple and I
shouldn't have to worry if I follow the right principles, that you
then go on to state (principles that aren't really that explicit
anywhere - such as "don't use XML-RPC to talk to ZOPE from ZOPE" and
"don't use mutable subobjects at all"). However, this is a further bit
of distance between a ZOPE user and the Python he knows, and it also
isn't as true for complex situations with complex requirements that I
could probably just jot down in "dumber" frameworks such as RoR or
Django or TurboGears. Because I know without having to check myself
where I am designing Data, I explicitly _make_ changes (to the DB) and
am thus very aware of where complex interactions might occur etc. This
is probably one of those cases where no one is really "right" because
a mixture of viewpoints is involved, I feel a bit as if we were
talking about wether Lisp is better than Smalltalk. However, even if
it is only the docs that are lacking I think it would be sensible to
acknowledge that as a problem. It obviously was a problem for me, as
of course was the complexity of my setup and several other factors. I
am not an inexperienced programmer, so I would think that just because
other people rarely stumble upon it it is not an insignificant
problem. Imagine designing a large system based on some only
marginally false assumptions about ZOPE transactions, persistence and
XML-RPC interaction, and then running into this in a key component.

Ole