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

[Andrew B. <an...@ca...>]

On Thu, Jul 14, 2005 at 01:00:52PM +0400, Oleg Broytmann wrote:
> On Tue, Jul 12, 2005 at 05:10:23PM +1000, Andrew Bennetts wrote:
> > This patch adds selectOne and selectOneBy methods to SQLObject, and simple
> > test cases for them.
> 
> > +        if len(results) == 0:
> > +            return None
> > +        elif len(results) == 1:
> > +            return results[0]
> > +        else:
> > +            raise SQLObjectMoreThanOneResultError(
> > +                "%d rows retrieved by selectOne" % len(results))
> 
>    You have named it selectOne, but allows empty reu;st. It is
> selectZeroOrOne, actually.

Yeah, it can explicitly return None.  Perhaps it would be better have a
default= keyword argument, and return that, or raise SQLObjectNotFound if a
default isn't given.  Think of it as analagous to dict.get.  And
selectZeroOrOne is a much more unwieldy name.

For most of our uses of it, the current behaviour seems to be ideal.

>    But in any case I don't like the idea. It does not add much. You'd
> better implement it in a base class in your application.

It's used over 100 times in our code (for Launchpad).  That would be a lot
tedious code without selectOne/selectOneBy!

We can keep it as a specific extension in our code, but I think this useful
for more than just us.  Has no-one else ever found themselves writing code
like this:

    results = Foo.select(...)
    try:
        # XXX: we really ought to assert there's no more than one foo...
        the_foo = results[0]
    except IndexError:
        raise FooNotFound
    return the_foo

several times?

In our code, this happens all the time, in places where alternateIDs and
SQLObject.get and so on don't help.

In fact, this can also be used instead of alternateIDs and get, which might
using SQLObject simpler and easier to learn... I'm not sure if this is a
good idea or not, but it is tempting.

-Andrew.