Chuck wrote:
>>Nevertheless MK _should_ support transactions, but this feature implementation is not scheduled any time soon (unless you want to contract me for it). Interestingly, I've heard (but not confirmed) that the Python Programming Patterns book builds an OO multithreaded transaction module/tool/whatever. That could be useful input. Also, there will be some kind of meeting or BOF about ORM, transactions, etc. involving both MiddleKit and ZODB folks at Python 10.<< Interesting that you bring up ZODB. I was rereading Andrew Kuchling's ZODB write-up at http://www.amk.ca/zodb/. It seems that it offers everything that one would want in terms of simplicity, transaction support, and (eventually) write-throughs to a RDBMS. Given this, I wonder whether it would simply be better to add ZODB into Webware, and deemphasize or drop MiddleKit? My reasoning (I'm not trying to be offensive, please take this as constructive discussion) is this: 1. Anybody who wants persistent objects can get it more easily with ZODB than MiddleKit/MySQL since ZODB can run directly off files. Not having MiddleKit/MySQL means one less thing to install and maintain. Not to mention that one need not know anything about SQL to use ZODB, but this is not true of MiddleKit/MySQL if efficiency is important. For example, finding all objects that have a certain attribute requires that either one uses server-side query options ("where..."), or suffer the inefficiencies of multiple selects into tables as one traverses an object space programatically. Kuchling seems to be saying that ZODB is less inefficient at this because of it's use of links between objects (see http://www.amk.ca/zodb/guide/node4.html). 2. Any transaction intensive or mission-critical application is likely to be deployed on an ACID-compliant RDBMS because: (1) programmers are likely to want very good control over transactions (2) end-users need standard ad-hoc query facilities using standard tools like Crystal Reports. Anybody who chooses an RDBMS for its ability to be tuned, and support ad-hoc queries is likely to want a more traditional relational model, so I think MiddleKit and other object-relational mapping layers are not useful here anyway. 3. Why reinvent the wheel? I understand that ZODB support for back-end RDBMS engines is now experimental. When more stable, it looks like it may do what MiddleKit does in terms of being able to be used as an object-relational mapper. 4. Why use MySQL when a simple file store like that used in ZODB will do? After all, the SQL that MySQL offers differs more from the SQL-92 standard than other RDBMS, so it's one more thing to learn. And, MiddleKit/MySQL users don't really want to use any SQL anyway. Further, MySQL probably doesn't offer any scalability beyond that provided by ZODB due to its use of table locking. Lastly, MySQL can't support transactions... 5. Why introduce unnecessary complexity into Webware (this point is related to point 1 above)? A MiddleKit/MySQL combination requires one to build an object model first, generate the SQL, create tables, maintain MySQL, etc. ZODB circumvents all these steps. Webware users can just live in Python, and never worry about all of this stuff. In summary, it seems to me that incorporating ZODB into Webware reduces complexity even as it adds functionality and robustness. ...Edmund. _______________________________________________ Webware-discuss mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/webware-discuss
