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
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
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 - Zope@zope.org
** No cross posts or HTML encoding! **
(Related lists -