[SQLObject] Re: SQLObject

On Thu, 2003-04-10 at 16:10, Steve Holden wrote:
> > > 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?

There is a KeyCol which I need to fill out a bit more, which will fill
that role.

As far as methodology in naming, I'd rather everyone was methodical. 
Having a style object could help that, because then you could make
explicit your style and when you create new tables or new columns it'll
be easier to stick with that style than otherwise.

> > 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, ...

As far as methodology in naming, I'd rather everyone was methodical. 
Having a style object could help that, because then you could make
explicit your style and when you create new tables or new columns it'll
be easier to stick with that style than otherwise.

> > > 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?

On the Python side a tuple wouldn't be that big a deal, dynamic typing
and all, but the SQL generation would have to change.  Maybe it wouldn't
be that hard, _idName becomes a tuple too and you're WHERE clauses just
become slightly more complex.  I dunno...

  Ian