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