[Zope] Zope Persistence (was: XML-RPC within ZOPE)

[Lennart Regebro]

On 12/18/05, Jan-Ole Esleben <esleben at 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/