> > but it happens under rather magical circumstances. That's my problem. Can you, from the ZOPE documentation, predict that the example below will cause a ConflictError? It doesn't if you alter it only slightly! Please try!
> > security.declareProtected("Use TestPChanged", "test_internal") > > def test_internal(self, args=None, args2=None): > > "Called by test via XML-RPC" > > if args2: > > self.a.append(1) > > self._p_changed = 1 > > if not args: > > import xmlrpclib > > s = xmlrpclib.ServerProxy("http://USER:[EMAIL PROTECTED]:8080/", > > allow_none=True) > > s.TestPChanged.test_internal(1) > > return self.a > > > > security.declareProtected("Use TestPChanged", "test") > > def test(self, args2=None): > > "Called directly via ZOPE" > > if args2: > > self.a.append(1) > > self._p_changed = 1 > > import xmlrpclib > > s = xmlrpclib.ServerProxy("http://USER:[EMAIL PROTECTED]:8080/", > > allow_none=True) > > return s.TPCDest.test_internal() > I don't understand the question. I would like to point out that you > set self._p_changed even when you don't change anything. :-) I know. This is just example code. Just imagine that both methods change completely unrelated sets of data in addition to not changing self.a. > It seems to me that you say that if you process calls test and another > calls test_internal, you get a conflict error. It doesn't really in most cases. And of course I can see now where it does in this instance, but this is based on Zope looking at the code, determining that self.a is changed before the _p_changed, and marking the object tainted because of that. > This is correct, and as > noted before, that code would create a conflict in any type of > environment. If you have two processes trying to modify the same > dataset, which is what your example seems to do, then you get a > conflict. > What you claim, is that if you have two processes in Zope change two > different datasets, you get a conflict. That statement is still false. Actually, I don't think we're getting anywhere with this same dataset/different dataset distinction. It wouldn't happen in a database using application because there would be no transaction for "self.a". You see, nothing happens to it, so why would there be one? This only happens when you mix your data with your code and have implicit transactions handled by the server. > Yes, sorry, having non-persistent aware dictionaries or arrays, and > then complaining that you have problems with persitency... But that's part of my point: I need to go out of my way to circumvent Python, and I need to be really careful, because using dicts and lists might still work. Nothing is enforced, and where it breaks is hard to predict. > > See the example for some major implicitness. > What is implicit with it? I explained this above. Transaction handling in Zope (someone else pointed that out in this thread), Zope looking at the code to determine that self.a has changed (which isn't really documented anywhere obvious). > > > You claim that things get locked that shouldn't be locked in Zope. It > > > is not clear to me why you say that. > > See the example. > I don't see how the example examplifies this. I have tried to make it a little clearer in this message. > It is obvious to me that you have misunderstood something. I don't > know what yet, though. I think we might be misunderstanding each other because we both place different value on implicitness and explicit design of data inside code. I am mostly talking about what is, pragmatically, good programming and a supportive environment. 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 )