[SQLObject] Re: SQLObject

[Steve H. <sh...@ho...>]

[Ian Bicking]


> I hope you don't mind me copying you to the list.
>
Not really, it's not like we were discussing my medical record or anything
:-)

> 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.
>
Just something that needed fixing: no biggie.

> > 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 :-/
>
Right. I think you should perhaps in that case state that normal
non-tranlsated names are the default. I was fooled into thinking I *had* to
use a single intial cap to access the existing schema, which is probably
wrong.

> > 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.
>
There you go. Concentrate on benefits, not features ;-)

> > 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.
>
I see. Generally you might find that many database designers and users
aren't terribly (as) methodical (as you seem to be) in naming their data
structures, so the more flexibility the better here. Would it be possible
(e.g.) to define a subclass of Col called PK that had the additional
semantics of identifying the named column as key. Alternatively an extra
Col.__init__() argument PK=False that flags a Col as being a key column?

> 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.
>
Style is a nice idea, but again this implies method in the DB madness. I
personally would be OK with some designs, since I do have naming
conventions, but I'm not rigorous about their use (yet). Let's see, a
3-character table prefix, hmmm, ...

> > 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.
>
I guess it's a YAGNI then.

> > 6. Under "Creating and Dropping Tables" you discuss creating a
*database*
> > rather than a *table*.
>
> FileMaker has infected me with its nefarious terminology!
>
Wash your mouth out with SOAP :-)

> > 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.
>
Well, I think I'd like the id to be a tuple, please. Refactoring would
presumably consist of bracketing all expressions assigned to the ID value in
the existing code?

> > Anyway, thanks for an interesting piece of software!
>
> And thank you for your careful reading of the documentation.
>
Well, not careful enough, since I still haven' treally delved into
many-to-many relationships.

I'd also like to hear ideas about a possible "web form rendering" mixin that
allows a collection of columns to be input from, or populate, a form in a
web page.

regards
--
Steve Holden                                  http://www.holdenweb.com/
Python Web Programming                 http://pydish.holdenweb.com/pwp/
Did you miss PyCon DC 2003?            Would you come to PyCOn DC 2004?