[SQLObject] Re: SQLObject

[Ian B. <ia...@co...>]

I hope you don't mind me copying you to the list.

On Wed, 2003-04-09 at 04:15, Steve Holden wrote:
> Ian:
> 
> I've just spent a little time looking at SQLObject, as I'm always interested
> in object-relational mapping frameworks. It's a nice idea, and please bear
> in mind these remarks relate to my own use of it. Whether you take them
> seriously enough to think about modifying something that clearly works for
> you is entirely up to you, and this isn't intended as criticism of your
> efforts. At leat you know that someone's taken ther trouble to review
> SQLObject. Specifically:
> 
> 1. You document the magic _idName, but people like me who only read the code
> samples end up using _id instead, and getting and "Unknown column id" SQL
> error.

Yes, you weren't the only one caught by this.

> 2. I found the name translations imposed by your scheme a little confusing.
> Is this because you've had a lot of experience with bizarre databases where
> people have taken liberties with the names (like including spaces in table
> and/or attribute names)? 

No, I haven't particularly.  Right now reasonable names should all work,
but spaces in attribute names won't.  I suppose it wouldn't be hard to
add the proper quotes in to make that possible (just backquotes,
right?), but I resist such forcefully bad names :-/

> Perhaps it might be better to avoid discussion of
> these issues until after the simple examples. Personally I think I'd prefer
> it if you used some other mechanism to map object names to database names
> (the one you use for columns is better than the one you use for tables) in
> those cases where python names can't be used for database objects.

Yes, it would probably make sense to start with automatic schema
generation (which is fast to get working with), and then have a section
on ways to adapt your class to a pre-existing table.

> 3. You talk about "relations" when I suspect you really mean
> *relationships*. Formally, a relation is what a table in a relational
> database represents, and it contains occurrences of a single entity-type
> identified by primary key value. A relationship is a mapping from
> occurrences of one entity-type to occurrences of another entity-type.

Noted and changed.

> 4. The whole business of using "id" as a default name for a primary key is
> somewhat contrived, and increases the difficulty of mapping SQLObject onto
> existing database schemas.

I don't have a lot of experience with pre-existing schemas, and I've
just adopted the style that I was first introduced to.  I realize it's
common to use tablename_id or tablenameid for the primary key, though I
don't see any particular advantage besides some sort of implicit column
matching between tables.

At some point I'll probably make some sort of Style object which you can
use to give your default method/database mapping functions.  Then people
who use different conventions don't have to go through too much trouble.

> 5. Your assertion that MySQL does not support transactions is out of date,
> since they can be supported by databases built from InnoDB tables, I believe
> (or have I imagined this?).

That's true.  But I've yet to meet someone actually using transactions,
and my own (admittedly brief) attempts to get transactions working were
unsuccessful.  I suppose it's possible, and there's no particular
barriers in place to keep someone from using transactions with MySQL (if
MySQLdb supports them...?), but until someone does it I find MySQL's
claim less than convincing.

> 6. Under "Creating and Dropping Tables" you discuss creating a *database*
> rather than a *table*.

FileMaker has infected me with its nefarious terminology!

> 7. I don't see any support for tables with composite primary keys. Is this
> an omission you plan to rectify?

I don't know.  I like single, simple primary keys.  They work well.  If
the table is really so minimal that it can't stand to have an extra
field for the id, then I suspect a SQLObject class is too heavy for it
(like with the join tables).  Of course, when adapting to a pre-existing
schema you might not have as many options.  Maybe it wouldn't be that
hard to fudge it (maybe make the ID into a tuple), but SQLObject really
expects for each object to have a single ID.

> Anyway, thanks for an interesting piece of software!

And thank you for your careful reading of the documentation.

  Ian