Re: [SQLObject] Col naming in MultipleJoin

[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 :)

Nick

On Sat, 2003-05-10 at 13:40, Luke Opperman wrote:
> 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
> 
> 
> 
> -------------------------------------------------------
> Enterprise Linux Forum Conference & Expo, June 4-6, 2003, Santa Clara
> The only event dedicated to issues related to Linux enterprise solutions
> www.enterpriselinuxforum.com
> 
> _______________________________________________
> sqlobject-discuss mailing list
> sql...@li...
> https://lists.sourceforge.net/lists/listinfo/sqlobject-discuss