> > To simplify, in ZOPE, for any given product, during a > > transaction the product is effectively locked. > This statement is incorrect.
You're right. It should be "during any transaction where there are potential changes to the object". And I agree, it's actually a lot more complicated than I'd thouht at first. What I describe can happen, but it happens under rather magical circumstances. I have an example where it actually happens; this is code from a product that is instantiated twice, one of those instances called TPCDest, the other TestPChanged; the method called directly is "TestPChanged.test()": 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() Zope obviously looks at the code, because if you remove the "if args2" (which is _never_ true), then a ConflictError happens. Maybe I'm stupid, but could someone point out _where_ exactly I am? > > No. It does happen, and it _did_ happen in my original problem. Zope > > doesn't even care if anything actually changes, it just considers an > > object changed that set self._p_changed=1. > No, se above. You're right that it doesn't always, but see my example. > Yes. You said "different sets of data". That reasonably means > different objects. If it doesn't, yuo need to take a long hard look at > your object hierarchy. Simply not true. What if I have a field titles (that is a hash of titles to Book objects) and a field comments (that is an array of comments on the library)? Is that so obviously not a sane example? > > > > That's my whole point. I think it is a very > > > > significant point nonetheless, because this is just an extreme case of > > > > what happens when you couple data and programs, and persistent classes > > > > are just that: application data inside program code. > > > Eh, no they aren't. > > Please don't just claim stuff. > You do. I don't. I at least try to give reasons wherever I make a statement that could be challenged. > > In ordinary systems, you would have to find a way to store the > > data and retrieve it, thus having a model that isn't implicit and > > entangled with your code. > What is implicit with it? See the example for some major implicitness. It's also implicit because you have no control over what a transaction considers a tainted object. (You have no real control over the transaction). > If you have two different processes changing the same set of data, you > will get confllict errors. You claim that you will not, but this is > false. I am explicitly talking about changing different sets of data within the same object. You noted that above yourself. > You claim that you can't control what a persistent class store. That is false. I don't. I say that if I want to avoid such problems as I describe altogether, I cannot store anything in a persistent class and thus lose most of what makes ZOPE so interesting. > You claim that the whole Zope product gets locked, that is false. It's > on a object-basis, not a product basis. I never said that, or at least I didn't mean it. If it sounded like that, I apologize (maybe I used Product metonymically for instance somewhere, which would not be a good idea, I agree). > 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. 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 )