Re: [Zope] Re: Zope Persistence (was: XML-RPC within ZOPE)
1. In the example, just setting _p_changed=1 does _not_ lead to a conflict error. With the ineffectual code above it (that never gets executed) it _does_. So there _is_ some implicit magical stuff going on and ZOPE tries to take care that only subobjects change (but incompletely)! I strongly doubt it. Zope does not inspect code. There must be a problem in your testing. Note that if self.a is a standard list, the self.a.append(1) doesn't have any impact on the persistence mechanism or transactions either. Please, try it out. Delete the if clause and the append in it. 3. It is especially confusing that ZOPE behaves differently when using XML-RPC calls. From what you say, it should be the same within the ZOPE system as when using XML-RPC. It gets more complicated with XML-RPC though! The successive XML-RPC call you describe provoke new transactions, surely you're aware of that? Whereas just calling a function of course doesn't. I'm aware of that. But ZOPE offers XML-RPC and as there is nothing in the documentation about such complex interactions. Also, I was directly responding to what the previous poster had written. Ole ___ 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 )
Re: [Zope] Re: Zope Persistence (was: XML-RPC within ZOPE)
On 12/18/05, Jan-Ole Esleben [EMAIL PROTECTED] wrote: I strongly doubt it. Zope does not inspect code. There must be a problem in your testing. Note that if self.a is a standard list, the self.a.append(1) doesn't have any impact on the persistence mechanism or transactions either. Please, try it out. Delete the if clause and the append in it. No, Zope does not do any code analysis. Code gets executed or not, and that's it. If you observe behaviour you can only explain by assuming un-executed code to have side-effects, you will have to re-examine your assumptions. Get a good debugger instead. -- Martijn Pieters ___ 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 )
Re: [Zope] Re: Zope Persistence (was: XML-RPC within ZOPE)
On 12/19/05, Jan-Ole Esleben [EMAIL PROTECTED] wrote: 1. In the example, just setting _p_changed=1 does _not_ lead to a conflict error. With the ineffectual code above it (that never gets executed) it _does_. So there _is_ some implicit magical stuff going on and ZOPE tries to take care that only subobjects change (but incompletely)! I strongly doubt it. Zope does not inspect code. There must be a problem in your testing. Note that if self.a is a standard list, the self.a.append(1) doesn't have any impact on the persistence mechanism or transactions either. Please, try it out. Delete the if clause and the append in it. Little bit tricky to try out as testers need to guess what all the missing code is. 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. Meanwhile I'm camping over at I-strongly-doubt-it. 3. It is especially confusing that ZOPE behaves differently when using XML-RPC calls. From what you say, it should be the same within the ZOPE system as when using XML-RPC. It gets more complicated with XML-RPC though! The successive XML-RPC call you describe provoke new transactions, surely you're aware of that? Whereas just calling a function of course doesn't. I'm aware of that. But ZOPE offers XML-RPC and as there is nothing in the documentation about such complex interactions. Also, I was directly responding to what the previous poster had written. Zope provides for XML-RPC as a server. And it does so with internal transaction support. 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). Either design to avoid this or get your hands dirty with transactions. Some starting points for examples would include any of the relational database adapters. Also in the same space is MaildropHost. 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 )
Re: [Zope] Re: Zope Persistence (was: XML-RPC within ZOPE)
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 ___ 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 )
Re: [Zope] Re: Zope Persistence (was: XML-RPC within ZOPE)
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 )
Re: [Zope] Re: Zope Persistence (was: XML-RPC within ZOPE)
Thanks, I will definitely look into that for my immediate problems. Ole 2005/12/16, Michael Haubenwallner [EMAIL PROTECTED]: Jan-Ole Esleben wrote: Thanks; this is a problem we are well aware of. Our solution is to increase the amount of workers, obviously. However, I'm increasingly getting a feeling that for a rather big range of unlikely situations that are nonetheless to be expected, Zope doesn't work _at all_. In a WebServices setting, situations like the one I described, with one server calling back to another server within a call from that latter server and both not knowing anything about the implementation of the other, it would most certainly be extremely hard to foresee the exact setup of such situations and impossible to exclude them for persistent objects that actually _do_ change state (unlike mine). The solution is to not have state in your objects, and thus lose instantly most of what Zope is. However, as I see it, the problem is that what Zope actually _is_ (i.e. mostly the ZODB) is an unhealthy way of coupling data and implementation (which is _exactly_ why my implementation didn't work immediately). This of course comes from its origins in TTW development where there wouldn't actually have been many user made products. Please tell me if I'm wrong with my assumption above, and why. I'm not trying to be inflamatory, this just has me really worried. Ole You could try XMLRPCMethod. It creates its own worker thread and has a configurable timeout. Michael [1] http://www.zope.org/Members/EIONET/XMLRPC -- http://zope.org/Members/d2m http://planetzope.org ___ 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 ) ___ 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 )
