On 12/19/05, Jan-Ole Esleben <[EMAIL PROTECTED]> 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 _______________________________________________ Zope maillist - Zope@zope.org http://mail.zope.org/mailman/listinfo/zope ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope-dev )