|
|
|
Added HQLTest.testAggregationReturnType to test for the above statements.
Consequence: COUNT changed from Hibernate.INTEGER to Hibernate.LONG MAX/MIN no changes AVG changed from being dependent on the field to only return Hibernate.DOUBLE SUM changed from always just return the type of the field to return according to the above rules. Stuff that falls besides these rules simply just return the underlying field/column type. e..g SUM(timestamp) will return timestamp; but will/should fail on the db. This is what we did before; let me know if the spec states something here or if a more strict rule is needed/wanted. also committed updated testsuite.
This change really breaks stuff. Users can work around this by specifying adifferent type for the different functions in the dialect...but be prepared for alot of questions like: assertionFailure: 0 not equals to 0 :) That's good regarding the spec.
I was ready to yet another switch flag but a straight change will cause less pain for the future I guess. We need to describe that in the migration page I would also prefer to have a flag or some way of influencing the dialect to be in pre-H3.2 compatibility mode as an option - but our dialects are statically defined so unless someone has suggestions for this then please speak up ;)
the only quirk is that currently the old query translator has hardcoded logic for the return value; but i guess that is not really critical. |
|||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
The Java type that is contained in the result of a query using an aggregate function is as follows[33]:
• COUNT returns Long.
• MAX, MIN return the type of the state-field to which they are applied.
• AVG returns Double.
• SUM returns Long when applied to state-fields of integral types (other than BigInteger); Double
when applied to state-fields of floating point types; BigInteger when applied to state-fields
of type BigInteger; and BigDecimal when applied to state-fields of type BigDecimal.