[Mondrian] Some dialect issues

Paul Stoellberger p.stoellberger at gmail.com
Sat Nov 17 10:27:33 EST 2012


I noticed that there is a requiresOrderByAlias() in the Dialect interface. 
However there is only 1 place in the code where this is really checked, the native topcount.

For dialects that don't allow expressions in the group by / order by this would be extremely helpful.
Same for databases that have to do a consistent selection (e.g. use a column the same way in the select, group by and order by.. no mix up between alias and column names, at least group by and order by have to be consistent)

We could call it requiresSelectGroupByOrderByConsistency() ;-)

Both dialects I was working on recently, Big Query and MonetDB had at least one of those cases.

I only made some quick hacks to make it work for Big Query, but I think it makes sense to implement this properly in the sql generator classes.
But before I start I would like to know if this even makes sense to do in the 3.5 / master branch or if I should only take a look at lagunitas!?
I know that 3.5 has become quite fragile and you are trying to avoid big changes... hence my question.

Additionally Big Query requires all columns used in the where / order by / group by to be in the select clause as well.
Do you think it makes sense to add this to the Dialect interface with a default to false in jdbcdialect, or should I just insert some checking for a specific database (big query in that case)?

Ad MonetDB Dialect.... in the CaptionTest there is a new schema that uses a SQL expression for the level Time.Years in Sales:
	<SQL dialect="generic"> "the_year" || '-12-31' </SQL>

This will resutl in queries like:
select "time_by_day"."the_year" as "c0", "the_year" || '-12-31' as "c1" from "time_by_day" as "time_by_day" group by "time_by_day"."the_year", "the_year" || '-12-31' order by CASE WHEN "time_by_day"."the_year" IS NULL THEN 1 ELSE 0 END, "time_by_day"."the_year" ASC

This is something I cannot fix without the requiresOrderByAlias() being fixed.
It's just a minor issue and probably an edge case, but this is responsible for at least 3-4 tests having errors


More information about the Mondrian mailing list