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

[Jan-Ole Esleben]

> > To simplify, in ZOPE, for any given product, during a
> > transaction the product is effectively locked.
> This statement is incorrect.

You're right. It should be "during any transaction where there are
potential changes to the object". And I agree, it's actually a lot
more complicated than I'd thouht at first. What I describe can happen,
but it happens under rather magical circumstances. I have an example
where it actually happens; this is code from a product that is
instantiated twice, one of those instances called TPCDest, the other
TestPChanged; the method called directly is "TestPChanged.test()":

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

Zope obviously looks at the code, because if you remove the "if args2"
(which is _never_ true), then a ConflictError happens.

Maybe I'm stupid, but could someone point out _where_ exactly I am?

> > No. It does happen, and it _did_ happen in my original problem. Zope
> > doesn't even care if anything actually changes, it just considers an
> > object changed that set self._p_changed=1.
> No, se above.

You're right that it doesn't always, but see my example.

> Yes. You said "different sets of data". That reasonably means
> different objects. If it doesn't, yuo need to take a long hard look at
> your object hierarchy.

Simply not true. What if I have a field titles (that is a hash of
titles to Book objects)
and a field comments (that is an array of comments on the library)? Is
that so obviously
not a sane example?

> > > > That's my whole point. I think it is a very
> > > > significant point nonetheless, because this is just an extreme case of
> > > > what happens when you couple data and programs, and persistent classes
> > > > are just that: application data inside program code.
> > > Eh, no they aren't.
> > Please don't just claim stuff.
> You do.

I don't. I at least try to give reasons wherever I make a statement
that could be challenged.

> > In ordinary systems, you would have to find a way to store the
> > data and retrieve it, thus having a model that isn't implicit and
> > entangled with your code.
> What is implicit with it?

See the example for some major implicitness. It's also implicit
because you have no control over what a transaction considers a
tainted object. (You have no real control over the transaction).

> If you have two different processes changing the same set of data, you
> will get confllict errors. You claim that you will not, but this is
> false.

I am explicitly talking about changing different sets of data within
the same object. You noted that above yourself.

> You claim that you can't control what a persistent class store. That is false.

I don't. I say that if I want to avoid such problems as I describe
altogether, I cannot store anything in a persistent class and thus
lose most of what makes ZOPE so interesting.

> You claim that the whole Zope product gets locked, that is false. It's
> on a object-basis, not a product basis.

I never said that, or at least I didn't mean it. If it sounded like
that, I apologize (maybe I used Product metonymically for instance
somewhere, which would not be a good idea, I agree).

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

Ole