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.

--
Mike Orr