Gavin King (
https://hibernate.atlassian.net/secure/ViewProfile.jspa?accountId=557058%...
) *commented* on HHH-16986 (
https://hibernate.atlassian.net/browse/HHH-16986?atlOrigin=eyJpIjoiMjg0YW...
)
Re: CoercionException caused by attempted coercion of query param to entity field type (
https://hibernate.atlassian.net/browse/HHH-16986?atlOrigin=eyJpIjoiMjg0YW...
)
You seem to be looking at it from a perspective of “how can we minimize
the amount of undefined behavior hibernate produces”.
Precisely. That’s one of the very clear and explicit goals of H6.
I’m looking at it from a perspective of “If I pass correct values (and
types) to Hibernate I’d like to get correct results”.
If Hibernate doesn’t know the types of things, it can’t possibly know what behavior is
“correct”, or guarantee that you’ll get it.
So from this point if view, the best solution is to be explicit about the types of
things.
But I guess a way to do math in HQL is desirable?
You don’t need implicit type conversions to do math. You can always fall back to doing
type conversions explicitly.
there needs to be a way to communicate the unknown types to Hibernate so
that it can know it’s in a valid case and does not error.
Which you can actually already do here by writing test.intField * cast(?1 as BigDecimal)
as I noted below.
On first glance it seems to be me that the information is already present
in a stronger the form of the parameter type.
Unfortunately, the information about bound arguments is not available at the time the
query is compiled. We compile the query when you call in createQuery() , not when you call
getResultList().
This is actually more important than it perhaps sounds: we have named queries which are
compiled at startup via @NamedQuery , and even for queries passed as strings we have a
QueryInterpretationCache. So we prefer to avoid having the semantics of the query depend
on the arguments you bind to parameters.
Look, I’m not implacably opposed to trying to solve this in some subset of cases. I’m just
trying to point out to you that the problem is quite a lot more subtle than you imagine.
So any “solution” would involve coming up with a sensible and clearly-defined bright-line
rule and not a bunch of band-aids that accumulate over time.
In the meantime, I think the workaround with cast() is really quite reasonable.
(
https://hibernate.atlassian.net/browse/HHH-16986#add-comment?atlOrigin=ey...
) Add Comment (
https://hibernate.atlassian.net/browse/HHH-16986#add-comment?atlOrigin=ey...
)
Get Jira notifications on your phone! Download the Jira Cloud app for Android (
https://play.google.com/store/apps/details?id=com.atlassian.android.jira....
) or iOS (
https://itunes.apple.com/app/apple-store/id1006972087?pt=696495&ct=Em...
) This message was sent by Atlassian Jira (v1001.0.0-SNAPSHOT#100233- sha1:f5b6255 )