From: Justin B. <jgb...@gm...> - 2007-11-21 19:43:00
|
All, This email asks for some design advice. I've been trying to remove the "distinct" clause and instead doing it the right way - grouping by each column in the select. I have tried several approaches, none of which has worked quite right: 1 - Make all columns aggregate and non-aggregate: In Sql/Default.hs, defaultSqlProject determines if any column has an aggregate expresion and, if so, it adds all non-aggregate columns to the groupby list. My first attempt updated an existing Project by adding a "AggrExpr" for each expression, using the "AggrSpecial" operation. This resulted in the columns correcltly moving to the group by, but Aggregates are always rendered as "functions" (e.g. COUNT( ..), AVG( ...)) so I got a lot of columns like "(bus_unit_id) as bus_unit_id1". I also got multiple nested selects, but I think that is because I don't quite understand the PrimQuery/Alias mapping when creating a new Project. 2 - Adding a new aggregate operation - I tried adding an AggrUnique constructor to the AggrOp type, but this quickly ran into the same problems as above. Ideally, I wanted to treat AggrOp as a ColumnSqlExpression when printing (in Sql/Print.hs), but AggrExpr does not have the right information with it - namely, a way to convert the column expression to a string. 3 - Adding a new special operation - Two special operators, "TOP" and "ORDER" are already defined. I tried adding a "Unique" operator but, unfortunately, the special operator handler doesn't have access to the associatoin list making up the select, and thus I could not updated the "groupby" field like I was able to do in #1. Any suggestions or thoughts about other approaches are welcome. Thanks in advance! Justin |