Re: [SQLObject] [PATCH] Add selectOne and selectOneBy methods

[<da...@eg...>]

On Jul 14, 2005, at 5:54 PM, Andrew Bennetts wrote:
> On Thu, Jul 14, 2005 at 04:28:19PM -0700, da...@eg... wrote:
> I don't think this is a serious problem with selectBy.  It's unlikely 
> that
> column names will clash with those keyword arguments.  If it is a 
> problem,
> we could use a convention like treating "orderBy_" as meaning a column 
> named
> "orderBy" -- I think I've seen that used in e.g. Nevow's "stan" API, to
> workaround the problem of "class" being a reserved word in Python but 
> also a
> common attribute in HTML.

For me the question of column names clashing
with the keywords is less of the issue than the
simple fact of using kwargs for two different
purposes. I also implemented what you have,
but ended up looking at code like:

     r = t.selectBy(col=val,
                  orderBy=ordercol,
                  this=that,
                  connection=c,
                  )

Now obviously I would regroup and make sure
that the "clause" kwargs came before all the
"option" kwargs, but after using this a bit I
decided the convenience just wasn't worth
the "ugly!" chorus in the back of my mind
and moved all of my use cases to select()
and reverted my mods.

I appreciate this is a matter of taste and
that I don't personally have to use selectBy()
in that way even if the extension patch gets in,
but that's my take on it.

>> I hope that's clearer. For the selectOne() functionality
>> I would suggest adding the kwarg 'unique' to select().
> I don't like this -- magic flags that make a method return a different 
> type
> of result smell bad to me.  The return type of a method ought to be
> consistent.

You're right on this one - I hadn't thought it
through enough. I retract my suggestion,
but would still prefer not proliferating selectXXX
methods.

> Another way to do this would be a method of SelectResults, but that 
> feels
> like an odd place for it:
>
>     foo = Foo.select(query).getOneOrNone()

Yeah, I'm not so sure about this either.

> I share your concerns about "there should be only one way to do it", 
> but in
> this case I think practicality beats purity.

I think you may be right for the selectOne() problem
(although I do wish someone would come up with
an elegant solution!).

> -Andrew.
>