Re: [SQLObject] Col naming in MultipleJoin

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

Quoting Nick <ni...@dd...>:

> see attached patch.  it basically puts the ID on for you instead of
> you
> having to do it in Col() so it doesn't break anything.  There's no
> reason to change the functionality other than I don't like forced
> naming
> conventions in this way :)

Yep, that's the condensed version of what I was suggesting: turn it
around, so that the column names you define are all the *python*
accessors, and the fact that it's a key is tacked on elsewhere (or
explicit, as dbName sometimes must be). (This makes the assumption
that I think we both share, that the 'correct' pythonic accessor is
directly to the object, and the secondary one is to the ID key
value.)

(although I personally wouldn't hardcode it into Col() either way,
rather make it a subclass of Col; your patch is minimally
code-invasive, but very disruptive of existing code. But I realize
it's mostly for private consumption only. :)

I suppose if I were writing ForeignCol as described in my last post,
I'd go one step further, and remove the duplicate verbage (which
exists whether it is ForeignCol or KeyCol) of saying 'foreignKey=':

 ForeignKey('mother', to='Person')

in the shortest form.

possible braindead implementation, requiring no changes to existing
Col implementation, ignoring directAttr idea:

class ForeignCol(Col):
  def __init__(self, name, **kw):
    to = popKey(kw, 'to')
    if to:
      kw['foreignKey'] = to
    newName = name + 'ID'
    Col.__init__(self, newName, **kw)