Ruben Gehring ( https://hibernate.atlassian.net/secure/ViewProfile.jspa?accountId=6401f5e... ) *commented* on HHH-16986 ( https://hibernate.atlassian.net/browse/HHH-16986?atlOrigin=eyJpIjoiMzVmNm... ) Re: CoercionException caused by attempted coercion of query param to entity field type ( https://hibernate.atlassian.net/browse/HHH-16986?atlOrigin=eyJpIjoiMzVmNm... ) Interestingly enough this query produces exactly the kind of result you’d expect when multiplying 2f with 2.5d : session.createQuery(""" UPDATE TestEntity test SET test.intField = ?1 * ?2 """) .setParameter(1, 2f) .setParameter(2, 2.5d) .executeUpdate() The query is update test_entity set int_field=(cast(? as float(24))*cast(? as float(53))) which seems perfectly correct to me, as far as parameter types go. It truncates the result but if that’s not intended it is user error, the framework does what it was asked. But honestly I don’t have a strong opinion on if narrowing should produce an exception or truncate. On the other hand I feel that the parameter types should be correct either way. Or, let me put it this way: Hibernate can resolve the param types correctly when no additional information is given. But give Hibernate more information by adding a known entity field to the calculation and suddenly parameter types are expected to be different to what they actually are. Yet from the outside it seems it should be easier to get the types right if Hibernate has more info available. That is why it tripped up my expectation of what would happen. ( 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 )