On 12/18/05, Jan-Ole Esleben <[EMAIL PROTECTED]> wrote: > 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.
Well, yes, but since both a and also b is non-persistence aware lists, that means that you in fact change neither a or b, but self. If however, you do change unrelated sets of data, such as the persistence aware object self.a, and the persistance aware object self.b, then you do NOT get a conflict error. > 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? There isn't one in this case either, unless you set self._p_changed = 1, which you of course do... > This only happens when you mix your data with your code and have > implicit transactions handled by the server. There is no mixing of data and code going on, so we are definitely not going anywhere with TAHT distinction. ;-) > > 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. No, it's dead easy to predict, as soon as you understand that you should not modify non-persistent aware attributes, and expect that to work optimally. You may be right that doing that should raise an error, but I also don't exactly see how to make that happen. > > > 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). I'm sorry, I still don't understand what implicitness you are talking about. > > 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. No, I think the misunderstanding is that you are overcomplicating something that is really quite simple. But I'm not sure. -- Lennart Regebro, Nuxeo http://www.nuxeo.com/ CPS Content Management http://www.cps-project.org/ _______________________________________________ Zope maillist - [email protected] 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 )
