On 12/18/05, Jan-Ole Esleben <esleben@gmail.com> 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/