SQLObject executing spurious COUNT(*) using slices

Assigning to spiv - I need a guess on how fixable this is. If it is going to be difficult or time consuming, we can work around this particular case and others as we track them down.

It looks a bit tricky.

The implementation of SelectResults.__len__ in our SQLObject invokes SelectResults.count (upstream doesn't do this). SelectResults.count (in both ours and latest upstream) does the COUNT without limit, then manually subtracts if there's a limit or offset (as is the case when slicing with [:5]).

I'm starting to wonder if we should reconsider the convenience of implementing __len__ (upstream certainly doesn't like it)...

A workaround for us may be to change SelectResults.count to do len([x for x in self]) if self.ops['start'] or self.ops['end'] is set. That will still issue a redundant query, but from what you're saying it will at least be cheaper. It might adversely impact other cases, though, although I'd expect all the objects it constructs would be constructed and cached anyway.

An alternative may be a flag to disable __len__ for a particular SelectResults instance? I don't really like this idea, though.

Perhaps we could make SQLObject cache this information, but doing that 100% safely would be a fair bit of work.

What are the benefits we get from len() working, apart from the syntactical benefit of being able to do len(results) instead of results.count()?

What stops us from changing count() to issue LIMITs when slicing?

I think the answer to the first of those questions will guide us in deciding whether to nuke, work around or cache. :-)

> What are the benefits we get from len() working, apart from the
> syntactical benefit of being able to do len(results) instead of
> results.count()?
>

The __len__ method allows us to use a SelectResults object in a boolean
context, which I find very handy, specially in page templates.

On Fri, Nov 25, 2005 at 09:03:06PM -0000, Guilherme Salgado wrote:
> The __len__ method allows us to use a SelectResults object in a boolean
> context, which I find very handy, specially in page templates.

Well, it also hides the fact that it issues a database query, which we
have found is dangerous.

Not to say I don't see your use case clearly:

    if results:
        for item in results:
            do_something
    else:
        print "there was nothing there"

I guess the only real way to keep this working the way you expect would
be caching.

The alternative, removing __len__, implies to me forcing the callsite to
convert the object to a list, always, before sending it into the
template. Is that a very big deal?

Guilherme Salgado wrote:

>>What are the benefits we get from len() working, apart from the
>>syntactical benefit of being able to do len(results) instead of
>>results.count()?
>
> The __len__ method allows us to use a SelectResults object in a boolean
> context, which I find very handy, specially in page templates.

We should define a __nonzero__ method for truth testing. This will still
require a DB query, but it can be optimized using LIMIT 1.

--
Stuart Bishop <email address hidden> http://www.canonical.com/
Canonical Ltd. http://www.ubuntu.com/

Fixed when James removed __len__ from SelectResults, I believe.