Re: [SQLObject] Col naming in MultipleJoin

[Luke O. <lu...@me...>]

Quoting Nick <ni...@dd...>:
>  The fact that you have to call a column somethingid is hardcoded
> in SQLObject.  I don't particularly like it, since it's clear in
> the Col definition that this is a foreign key.  I don't particularly
> see the downside in having to say pn.Person.id vs. pn.PersonID.
> I think it's more clear if you're really making an object oriented
> model.

Hmm, would you expand on this slightly? In our usage, yes, we almost
always use pn.Person.id, and .

The problem is that _columns/_joins defines the structure of the
database, and the pythonic access mechanisms appear by magic *for
some columns, and for all joins*. (somewhere around here I wrote up a
one-page summary of magic that happens, maybe it'd be useful in the
docs? I think it's all there already, this is just a summary of
'unexpected' things, to have people know they don't need to do
personID=myPeep.id, for instance.)

My question is: what would you prefer the initialization for
foreignKey's be? I'll throw out my idea, which is based on the fact
that in general, we specify the *python* attribute name as the column
name, and the dbName is optional:

  ForeignCol('person', foreignKey='Person')

would assume (based on Style object?) the dbname is person_id, and the
direct ID python access stays as "personID" (since I think there are
cases where there's justification for retaining immediate access to
the actual key values).

  ForeignCol('person', foreignKey='Person, dbName='person',
directAttr='personId')

Not sure on the nam 'directAttr', but this would be the mechanism for
overriding the direct python access name.

This doesn't have to require a change to existing code, as all other
columns could still take the foreignKey argument; this column-type is
just a shortcut that may make more sense for some people. Depending
on what people say, this could become KeyCol, or not (for
backwards-compatibility issues).

Thoughts?

- Luke