History | Log In     View a printable version of the current page.  
Issue Details (XML | Word | Printable)

Key: HHH-1538
Type: Improvement Improvement
Status: Closed Closed
Resolution: Fixed
Priority: Major Major
Assignee: Unassigned
Reporter: Emmanuel Bernard
Votes: 0
Watchers: 0
Operations

If you were logged in you would be able to see more operations.
Hibernate Core

aggregations functions in EJBQL queries does not return the appropriate types

Created: 01/Mar/06 06:47 PM   Updated: 29/Jan/07 05:59 AM
Component/s: core
Affects Version/s: 3.2.0.alpha1
Fix Version/s: 3.2.0.cr2

Time Tracking:
Not Specified

Issue Links:
Fix
 


 Description  « Hide
EJB3 requires a Long, not an Integer

 All   Comments   Work Log   Change History   FishEye      Sort Order: Ascending order - Click to sort in descending order
Emmanuel Bernard - 02/Mar/06 06:19 PM
Actually the spec says

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.

Max Rydahl Andersen - 04/May/06 08:35 AM
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.
 

Max Rydahl Andersen - 04/May/06 11:06 AM
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

:)

Emmanuel Bernard - 04/May/06 02:16 PM
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

Max Rydahl Andersen - 04/May/06 02:27 PM
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.

Dmitry - 29/Jan/07 05:05 AM
Just moved to 3.2 and it seems like Criteria's rowCount projection still returns Integer, not Long.

Max Rydahl Andersen - 29/Jan/07 05:59 AM
criteria is not EJBQL queries.