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

[Michael Dunstan]

On 12/19/05, Jan-Ole Esleben <esleben at gmail.com> wrote:
> > 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.

/me shurgs. I prefer code that runs. :-)

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

Joining many transactional systems into one mega transactional beast
is requires attention to details.

How about getting away from this notion a mega transaction with nested
transactions? For example, make use of transaction.commit() before
making XML-RPC calls. Though you well need to decide what happens in
the event of a ConflictError being thrown from somewhere else and
causing the initial request to be retried.


michael