Re: [SQLObject] Joins

[Ian B. <ia...@co...>]

Michel Thadeu wrote:
>>>>class Barrel(SQLObject):
> 
> ...   monkeys=MultipleJoin('Monkey')
> ...
> 
>>>>class Monkey(SQLObject):
> 
> ...   barrel=ForeignKey('Barrel')
> ...
> 
>>>>barrel=Barrel()
>>>>monkey=Monkey(barrel=barrel)
>>>>isinstance(barrel.monkeys, (list, tuple))
> 
> True
> 
> Why this is true?  Why can't the join return a select object, this way,
> if I need to count the monkeys of a barrel, I can use
> barrel.monkeys.count(), I can use sum() and other aggregate function I
> want... The actual way I need to rewrite the join to be able to apply
> these aggregate functions, or I use python to calculate what I need..

No good reason, except perhaps the original order that I implemented 
these features (complex select results after joins).

I'm also unhappy with select results, as they can be *too* lazy.  For 
instance, you can't test for truth value (to see if the query returns no 
rows).  I'm thinking that select results should be more stateful, but 
lazily so, caching the results.  This might help resolve some of the 
problems with databases that can't use multiple cursors -- if you make a 
query and there's another cursor waiting to finish its query (a lazy 
select iterator), it could quick finish before the other query was 
allowed to run, pushing its results into the SelectResult's cache.

It would be neat if, for instance, you could add to the query in of a 
select result.  Like barrel.monkeys.query(Monkey.q.species=='Spider'), 
which would be equivalent to Monkeys.select(
Monkey.q.barrel==barrel).query(Monkey.q.species=='Spider') , which would 
be equivalent to Monkey.select(AND(Monkey.q.barrel==barrel, 
Monkey.q.species='Spider')).

-- 
Ian Bicking  /  ia...@co...  /  http://blog.ianbicking.org