Re: [hibernate-dev] criteria + SUM
We fail because we return Long and not Integer, correct?
That's one of the latest changes we did in the spec (the addition of the sumAsLong /
sumAsDouble, especially for the case where you sum two integers.
"
> We will add the following 2 methods to the QueryBuilder(now
CriteriaBuilder)
> interface to support the JPQL semantics of returning Long when integers are
> summed and Double when floats are summed:
"
It looks like the spec has a bug, while the TCK is correct.
You can challenge the TCK but if the TCK test does sum two integers and return an integer,
that's the intend of the spec commitee and I would rather get us follow this line.
Emmanuel
On 7 janv. 2010, at 16:27, Steve Ebersole wrote:
My understanding is that the return types for aggregation function
in
criteria queries should follow the same rules as defined for JPAQL. So
first, is that a correct understanding?
The confusion is the type signatures of the builder methods, espcially
the ones that "change" based on the argument types. SUM, for example,
says the following in the JPAQL section:
<quote>
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.
</quote>
So for a SUM of int or Integer fileds, JPAQL is clearly expecting back a
Long.
The CriteriaBuilder sum method, however, is defined as:
<N extends Number> Expression<N> sum(Expression<N> x);
Which implies that when applied to an int or Integer field/expression
should return an Integer. Yes, I realize the last spec version added
the sumAsDouble/sumAsLong methods, but that is still not really the same
as the JPAQL rules.
The TCK does explicitly have a test for this btw and we are currently
failing. *However* even the test notes show the confusion here as it
states:
<quote>
Execute a query which contains the aggregate function SUM.
SUM returns Long when applied to state-fields of integral types.
</quote>
Unfortunately as soon as it says that is goes off and actually asserts
the return is a Integer ;)
So I am trying to decide if this need be a challenge based on "alignment
with JPAQL rules", a challenge based on something else you might see or
an inconsistency JPA users will have to live with?
--
Steve Ebersole <steve(a)hibernate.org>
Hibernate.org