I meant to send this to the Quixote list but sent it to the Durus list
instead. Additional comments at end.
---------- Forwarded message ----------
From: Mike Orr
Date: Oct 21, 2006 3:34 PM
Subject: Re: [Quixote-users] newbie mod_python+quixote+dojo
To: "Sells, Fred" , durus-users@mems-exchange.org
On 10/21/06, Sells, Fred wrote:
> 2. I've been using SQLObject, and found it programmer friendly. Does anyone
> have a comparison of SQLObject to DURUS without starting a flame war ;).
I tried SQLObject in a project and ended up switching to Durus. If
you want to use objects rather than a relational database, why not go
all the way? Object-relational mappers are like putting lipstick on a
pig. If you think foreign keys, flat tables, etc are programmer
friendly, you haven't used an object database. Literally 90% of the
work disappears. The SQLObject and SQLAlchemy manuals are a hundred
pages because even trying to put an OO front end on a SQL database is
a complex task.
I ended up using just the SQL writer from SQLAlchemy and skipping the
object stuff because it was more straightforward (SQLObject didn't
separate the two and wasn't as far along in development or
documentation), then I threw it all away and went to Durus when it
proved to be both faster and more reliable in my application. With an
ORM (object-relational mapper), both the ORM and the database backend
*and* the Python DB-API library are points of failure. I've been using
MySQL and a homegrown SQL generator for years with other sites, but
this site had several problems in MySQL and Python due to their
treatment of non-ASCII characters. SQLite would often just completely
hang when I did searches. Apparently that's due to a threading bug in
the Pysqlite library, but I can't wait for it to be fixed. Durus is a
small pure Python package (except for one small optional C module), so
it's only one point of failure and relatively easy to debug. However,
if you're doing frequent writes, especially concurrently or modifying
objects in place, you'll run into Durus's limitations. But I've never
seen Durus hang or crash.
---- End forward ---
Oleg wrote:
> Becuase SQL servers and SQL langauge have a lot of facilities OODBs
> dont. Langauge-independence (you can write clients in any language),
> scalability (ZODB's and Durus' FileStorages maintain an in-memory index,
> which is a problem for tasks with millions of objects) administration
> tools, access permissions, relational algebra
These are is all true. What one has to ask though is, how important
are these features to my application(s)? I made some assumptions in
my last post about the size/nature of a typical web application. I've
made several sites using MySQL that, looking back, didn't necessarily
need it.
It's easy to write a Python program that copies the data from one
database system to another. It's easy to write a program that
generates a custom report
or inspects the values or makes a change across the entire database.
These take the place of general administration tools. And for the
paranoid, you can dump the database to CSV files in case it becomes
corrupt someday. I do sometimes get tired of not being able to write
a one-line SQL query instead of:
# Equivalent of "SELECT COUNT(*) FROM my_table WHERE ...".
$ durus -c --file=foo.durus --readonly
>>> count = 0
>>> for o in root["my_dict"].iteritems():
>>> if SOMETHING(o):
>>> count += 1
>>> print count
or similar for counting/displaying records or unique values. So I
wrote a program that did that, at least in a limited way for my app.
You pass in a field name or expression and it does the statistics for
you. A general query tool of this nature would be useful.
On the other hand, not having to build and query multiple
relationships is a big win for me. I know SQLObject/SQLAlchemy are
supposed to hide that complexity for you, but it all comes back if you
use the non-Python "administrative tools" and want to do a query with
a many:many relationship or multiple relationships.
--
Mike Orr