On Thursday 27 December 2001 02:46 pm, Edmund Lian wrote:
> 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:
Webware is not a black box. If you want to write a WebKit application
that uses ZODB, or any other python product, feel free. We won't be
dropping MiddleKit (MK) for reaons you'll see below:
> 1. Anybody who wants persistent objects can get it more easily with
> ZODB than MiddleKit/MySQL since ZODB can run directly off files. Not
Let's qualify that: "anybody who wants persistent objects _NOT in a SQL
database_"
> having MiddleKit/MySQL means one less thing to install and maintain.
But you propose "replaced by ZODB" so we don't save much for those who
know neither. Both approaches have pros and cons that have to be
learned.
> 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.
There are costs of using SQL, but there are also benefits. They've been
discussed before so for now I'll avoid most of those details.
> 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).
The answer to whether or not MiddleKit/SQL is more or less efficient
than ZODB requires more than speculation. You'd basically have to test
it out, keeping as many other things as constant as possible. Even then
you could find that it varies by application.
> 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.
I do real work with MiddleKit. I enjoy having SQL access to my data
using various tools. I like what I perceive to be pretty good speed in
getting my data back.
Also, it's a common misperception that MK forces you to abandon a more
traditional relational model admittedly because the docs don't mention
anything about this.
> 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.
"When more stable, ...it may..." means that ZODB needs more
development. Well, so does MK. If ZODB is enhanced to map Python
objects to SQL, wouldn't that be reinventing the wheel? MK does it
today.
But more specifically, there was no Pythonic Object<->SQL mapper with
docs, test suite, etc. out there when I built MK. And I don't think
there is today either. dbObj was the closest thing.
> 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
"ZODB will do" is a statement that works for you, but obviously not for
everyone (same as with "MiddleKit will do"). I enjoy the tools that the
MK approach lets me use such as the MySQL GUI clients, the SQL prompt,
mysqldiff (yeah!), the vast knowledge base of articles on SQL & MySQL
tip, tricks and traps, etc.
I also get what feels like very good speed, although I'm not claiming I
wouldn't with ZODB; I haven't tried.
> standard than other RDBMS, so it's one more thing to learn. And,
Some of us already know MySQL. Others don't mind learning it.
> MiddleKit/MySQL users don't really want to use any SQL anyway.
...when we can use objects instead which is what MK gives you. And I do
want to use SQL on occasion. For example, I perform many on-the-fly
admin tasks from a SQL prompt.
> 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...
MySQL 4.0 supports transactons. I'm not sure if they have row level
locks yet or not. Also, if MySQL needs more work, so what? You already
said ZODB needs more work. Hey, MK does too and apparently Python is
still under active development.
We all need more work. :-)
> 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.
The more I use MiddleKit the more uses I have for the object model:
- generating forms
- generating object browsing pages
- generating detailed views
- generating sample data
- generating SQL table definitions
- generating runtime SQL
Note that SQL now occupies less than half the list of uses for an
object model.
The pay off to using the object model is that it is very easy to edit
and all of the above things automagically work right after the edit
(with the occasional caveat).
I plan on revamping the docs for MK to reflect an "object model"
approach and donating some more code for the above tasks.
> In summary, it seems to me that incorporating ZODB into Webware
> reduces complexity even as it adds functionality and robustness.
I think over time we'll see people use various combinations with
Webware:
1 pickles
2 SQL + DB API
3 SQL + MiddleKit
4 ZODB
I think 1-3 have; haven't heard about 4.
I don't expect that MK or ZODB or pickles are the perfect solution for
all applications. I do think that MK's object model approach is a
great one for _most_ applications, although most newbies won't feel
that until I revamp the docs and upload some of the things I mentioned.
**Nothing** about the app server dictates which of the above choices
you make. Feel free to install ZODB and write a WebKit app that uses
it. WebKit gets along with just about all Python packages except
perhaps another servlet framework (for obvious reasons).
Also if you have any specific experiences that relate to WebKit+ZODB
feel free to donate your knowledge to the Wiki. I prefer the
MK/object-model approach, but I'm NOT anti-ZODB (just
anti-environments-that-lock-you-in-to-one-approach).
-Chuck
|