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

[Jan-Ole Esleben]

What you say is all perfectly true except:

1. In the example, just setting _p_changed=1 does _not_ lead to a
conflict error. With the ineffectual code above it (that never gets
executed) it _does_. So there _is_ some implicit magical stuff going
on and ZOPE tries to take care that only subobjects change (but
incompletely)!

2. You shouldn't use lists and dicts - it should say this "on the
front page". It is never really mentioned in any way that intuitively
leads to such problems as we are now talking about. It isn't very
obvious that things work like this when you look at the documentation,
and

3. It is especially confusing that ZOPE behaves differently when using
XML-RPC calls. From what you say, it should be the same within the
ZOPE system as when using XML-RPC. It gets more complicated with
XML-RPC though! All the stuff that you claim as being obvious really
isn't all that obvious. And of course, once you've been burned by
something like this and the confusion it engenders, you will only use
PersistentMapping etc., but I still don't know what _exactly_ to
expect from ZOPE in terms of behaviour with mutable objects that
aren't Persistent (because of the XML-RPC inconsistency and the
self._p_changed inconsistency both mentioned above).

Ole


2005/12/18, Lennart Regebro <regebro at gmail.com>:
> 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/
>