Re: [SQLObject] SQLObject's joins; GROUP BY

[Oleg B. <ph...@ph...>]

On Wed, Aug 20, 2008 at 01:52:51PM -0700, Golemon, Buck wrote:
> To do multiple-table joins needs to do a graph search. More specifically
> a Steiner graph search. I have an implementation that I was planning to
> put on top of SQLObject to achieve this. If you want to think about
> adding this as a feature to SQLO, I'd be very happy to talk about it.

   SQLObject-style thinking is, as far as I understand it, to declare
relationships explicitly. So if SQLObject know there are Table1, Table2 and
Table3, and Table1 linked to Table2 with a straight join
   Table1.q.t2_id == Table2.q.id
Table2 is joined with Table3
   Table2.q.t3_id == Table3.q.id
then SQLObject can construct 3-tables join just AND'ing these conditions,
right?
   (Table1.q.t2_id == Table2.q.id) &
   (Table2.q.t3_id == Table3.q.id)
Isn't it enough?

> For the groupby api, I was thinking something like: 
> 
> MyTable.select().groupby("col1", "col2")
> or maybe
> MyTable.select().groupby(MyTable.col1, MyTable.col2)
> or even
> MyTable.select(..., groupby=("col1", "col2"))
> 
> Whichever fits the existing style best.

   GROUP BY is used with aggregate functions. Your examples lists columns
to GROUP BY by, but where is an aggregate?

> I'm not sure how the column types are relevant here.

   For MyTable.select() SQLObject knows what columns to return and how to
convert them from SQL to Python. With your proposed API SQLObject doesn't
know what columns to return, how to name them in SQL and in Python, how to
convert values from SQL to Python...

Oleg.
-- 
     Oleg Broytmann            http://phd.pp.ru/            ph...@ph...
           Programmers don't die, they just GOSUB without RETURN.