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

[Jan-Ole Esleben]

> > > > That ZOPE raises an error is fine. That I _might_ run into such
> > > > situations with other tools is true.
> > > You *will* run into these problems in exactly the same cases in any other tool.
> > I'm sorry, but that's just wrong, and I have given examples of such
> > situations. To simplify, in ZOPE, for any given product, during a
> > transaction the product is effectively locked. So if I have, say, a
> > list field that contains some data and a dictionary field that
> > contains some other data, and the "internal" call changes the dict
> > while the original call changes the list, that breaks the transaction,
> > while in usual situation in a database, nothing would break.
> This is wrong IMHO. dict and list are just columns of the same tuple
> if you speak RDBMS. And there are very few (if any?) databases
> which do locks only per column. In RDBMS you distribute in different
> tables to avoid such (e.g. normalize) in ZODB, you just make
> subclasses of Persistent for your subobjects. (Attributes)

I'm not saying that it absolutely can't be done, it is just very
difficult to do it right from the start because most of time you are
not even aware you are fiddling with the data model. This of course
isn't - I stressed that before - a problem for small scale
development. But if you do more complex stuff with ZOPE it's a bit
like going back to C - most of the mistakes in your design don't come
back to you until much later. However, unlike C, ZOPE is very high
level, and the problems stem from too much implicitness and too little
separation of said data and code. When you design your model, you know
that you are designing data and you handle those data as data
explicitly. When you add a field to your class, you have to explicitly
check yourself. And of course you could now answer "You should be
doing that anyway" and that nothing hppens in perfectly designed code
etc., but that's just not how it really works. You should be able to
design stuff incrementally with a little experimentation along the way
without constantly impending danger of it all crashing down on you.
That's how Python works, and RoR etc. In ZOPE, we're back to the
temptation to "just stuff a bunch of data into my object". And it's
not even obvious that this is a problem, because everything is so
tightly interdependent. It's exactly what Python usually avoids
("explicit is better than implicit").

Ole