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