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

[Jan-Ole Esleben]

> > but it happens under rather magical circumstances.

That's my problem. Can you, from the ZOPE documentation, predict that
the example below will cause a ConflictError? It doesn't if you alter
it only slightly! Please try!

> >   security.declareProtected("Use TestPChanged", "test_internal")
> >   def test_internal(self, args=None, args2=None):
> >     "Called by test via XML-RPC"
> >     if args2:
> >         self.a.append(1)
> >     self._p_changed = 1
> >     if not args:
> >         import xmlrpclib
> >         s = xmlrpclib.ServerProxy("http://USER:PASSWORD@localhost:8080/",
> >             allow_none=True)
> >         s.TestPChanged.test_internal(1)
> >     return self.a
> >
> >   security.declareProtected("Use TestPChanged", "test")
> >   def test(self, args2=None):
> >     "Called directly via ZOPE"
> >     if args2:
> >         self.a.append(1)
> >     self._p_changed = 1
> >     import xmlrpclib
> >     s = xmlrpclib.ServerProxy("http://USER:PASSWORD@localhost:8080/",
> >         allow_none=True)
> >     return s.TPCDest.test_internal()

> I don't understand the question. I would like to point out that you
> set self._p_changed even when you don't change anything. :-)

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.

> It seems to me that you say that if you process calls test and another
> calls test_internal, you get a conflict error.

It doesn't really in most cases. And of course I can see now where it
does in this instance, but this is based on Zope looking at the code,
determining that self.a is changed before the _p_changed, and marking
the object tainted because of that.

> This is correct, and as
> noted before, that code would create a conflict in any type of
> environment. If you have two processes trying to modify the same
> dataset, which is what your example seems to do, then you get a
> conflict.
> What you claim, is that if you have two processes in Zope change two
> different datasets, you get a conflict. That statement is still false.

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?
This only happens when you mix your data with your code and have
implicit transactions handled by the server.

> 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.

> > 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).

> > > You claim that things get locked that shouldn't be locked in Zope. It
> > > is not clear to me why you say that.
> > See the example.
> I don't see how the example examplifies this.

I have tried to make it a little clearer in this message.

> 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.

Ole