Comment 2 for bug 4818

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.