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

[Tino Wildenhain]

Am Samstag, den 17.12.2005, 16:43 +0100 schrieb 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").

Partly agreed. But then in zope, simple things are simple and
complex things complex. Dont say interlocking transactions
are simple anywhere else :-) If you want to do advanced stuff
you need to get deeper into the concepts. Unfortunately there
is no easy way. But now we figured it out, didnt we? :-)
Thats why these lists exist - nobody can probably get things
right from the start.

Happy coding
Tino