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 _______________________________________________ Zope maillist - Zope@zope.org http://mail.zope.org/mailman/listinfo/zope ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope-dev )