[Mondrian] [Fwd: Eigenbase perforce change 9873 for review]

Rushan Chen rchen at lucidera.com
Wed Sep 12 14:04:24 EDT 2007

Julian Hyde wrote:
>> Rushan's change below is checked in as LucidDB-specific, but 
>> according 
>> to SQL:2003, generating exponential literal format for 
>> double-precision 
>> values should always be the right thing to do, since without an 
>> exponent, the DBMS is supposed to interpret the literal as a 
>> fixed-point 
>> value.
>> In cases like this, is it preferable to "not rock the boat" by making 
>> the change LucidDB-specific?  The alternative is to change 
>> Mondrian to 
>> make it expect SQL:2003 behavior from the DBMS by default, and change 
>> other dialects as needed (e.g. if a DBMS does not support the 
>> standard 
>> exponential format).
>> (Don't ask why anyone would be crazy enough to use 
>> floating-point values 
>> as member keys in the first place.)
> The dubious thing in Rushan's change is the assumption that a Double value
> in java maps to a DOUBLE column in SQL. The datatype of the value in java
> depends as much on the JDBC driver as anything. I guess the driver should
> use BigDecimal for fixed-point values, but many of them use Double instead.
> I wouldn't think it is safe to extend this assumption to other databases and
> JDBC drivers, so the prudent thing is to keep this as a LucidDB-specific
> change.
> Julian
> _______________________________________________
> Mondrian mailing list
> Mondrian at pentaho.org
> http://lists.pentaho.org/mailman/listinfo/mondrian

The Java types of SQL columns are in fact implementation dependent. 
However, there's no new assumption made in my change as far as type 
inference goes. Note that Mondrian uses Double.toString() to generate 
the SQL for Double values. The toString() method produces 
"E..."postfixes for Double values which are not in the range 1E-3 and 
1E7. The change I made causes all Java Double values, including the ones 
in the range 1E-3 and 1E10, to have exponent postfix in SQL.

Some DB like MySql is not sensitive to the fact that literals of the 
Java type Double could be represented either as a DECIMAL SQL string(if 
between 1e-3 and 1E7), or a DOUBLE SQL string(if values are outside that 
range). Type cast will take care of the difference. However, this is not 
the case with LucidDB(due to its limited Decimal precision). So LucidDB 
has to require the client to produce literals that will guarantee the DB 
interprets them as DOUBLEs, as specified by SQL:2003. In short, the 
change is only required for LucidDB but will not be incorrect even 
extended to other DBs as long as they are SQL:2003 compliant when 
interpreting DOUBLE SQL literals.


More information about the Mondrian mailing list