July 2023 - hibernate-issues - Jboss List Archives

[JIRA] (HHH-16986) CoercionException caused by attempted coercion of query param to entity field type

by Ruben Gehring (JIRA)

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=EmailN... ) This message was sent by Atlassian Jira (v1001.0.0-SNAPSHOT#100233- sha1:f5b6255 )

2 years, 8 months

1
0
0 / 0

[JIRA] (HHH-16986) CoercionException caused by attempted coercion of query param to entity field type

by Gavin King (JIRA)

Gavin King ( https://hibernate.atlassian.net/secure/ViewProfile.jspa?accountId=557058%... ) *commented* on HHH-16986 ( https://hibernate.atlassian.net/browse/HHH-16986?atlOrigin=eyJpIjoiNGRmND... ) Re: CoercionException caused by attempted coercion of query param to entity field type ( https://hibernate.atlassian.net/browse/HHH-16986?atlOrigin=eyJpIjoiNGRmND... ) > > > > For example passing 2.5d and 2f to a calculation expected to return Integer > seems fine to me, and I would expect the result of (int) (2.5d * 2f) to be > 5. > > This is OK as you’ve written it, because the narrowing type conversion is explicit. But that’s not the case in the examples we’re considering. For example, Java doesn’t let you write: int i = 2.5d * 2f; And quite rightly so. Your example of ?1 * ?2 is actually the exceptional case because here both sides of the numeric operator have unknown types, so no type can be inferred. ( 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=EmailN... ) This message was sent by Atlassian Jira (v1001.0.0-SNAPSHOT#100233- sha1:f5b6255 )

2 years, 8 months

1
0
0 / 0

[JIRA] (HHH-16986) CoercionException caused by attempted coercion of query param to entity field type

by Ruben Gehring (JIRA)

Ruben Gehring ( https://hibernate.atlassian.net/secure/ViewProfile.jspa?accountId=6401f5e... ) *commented* on HHH-16986 ( https://hibernate.atlassian.net/browse/HHH-16986?atlOrigin=eyJpIjoiMGE2OT... ) Re: CoercionException caused by attempted coercion of query param to entity field type ( https://hibernate.atlassian.net/browse/HHH-16986?atlOrigin=eyJpIjoiMGE2OT... ) Ah, didn’t see your response when I posted my last one 😄 In any case I agree that “would be nice but technically speaking it’s not feasible” is often a reasonable answer to these kinds of problems. The general problem of having any kind of operand in any kind of operation seems hard I agree. And I can understand that you’d prefer not to build a thousand special cases and exceptions, I wouldn’t want to do that either. Mostly it seemed to me that Hibernate basically does parameter resolving and type casting correctly in most other cases and from the outside it’s not obvious that it’s easier for hibernate to identify param types correctly in calculations like ?1 * ?2 than in calculations like test.intField * ?1. Plausibly it is much harder to get the latter right, I don’t know, but I hope you can understand the confusion and why my default expectation was that if the first works then the second should probably work, too. In any case, explicit casting does indeed work, although I’m still figuring out which parts of the query I have to cast explicitly in order for hibernate to deduct all involved operands correctly. ( 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=EmailN... ) This message was sent by Atlassian Jira (v1001.0.0-SNAPSHOT#100233- sha1:f5b6255 )

2 years, 8 months

1
0
0 / 0

[JIRA] (HHH-16986) CoercionException caused by attempted coercion of query param to entity field type

by Gavin King (JIRA)

Gavin King ( https://hibernate.atlassian.net/secure/ViewProfile.jspa?accountId=557058%... ) *commented* on HHH-16986 ( https://hibernate.atlassian.net/browse/HHH-16986?atlOrigin=eyJpIjoiZWYzOG... ) Re: CoercionException caused by attempted coercion of query param to entity field type ( https://hibernate.atlassian.net/browse/HHH-16986?atlOrigin=eyJpIjoiZWYzOG... ) Actually, a better way to write the workaround is: select test.intField * cast (?1 as BigDecimal) which is in essence the same as the “new syntax” I’ve been toying with. ( 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=EmailN... ) This message was sent by Atlassian Jira (v1001.0.0-SNAPSHOT#100233- sha1:f5b6255 )

2 years, 8 months

1
0
0 / 0

[JIRA] (HHH-16986) CoercionException caused by attempted coercion of query param to entity field type

by Ruben Gehring (JIRA)

Ruben Gehring ( https://hibernate.atlassian.net/secure/ViewProfile.jspa?accountId=6401f5e... ) *commented* on HHH-16986 ( https://hibernate.atlassian.net/browse/HHH-16986?atlOrigin=eyJpIjoiOTQyYW... ) Re: CoercionException caused by attempted coercion of query param to entity field type ( https://hibernate.atlassian.net/browse/HHH-16986?atlOrigin=eyJpIjoiOTQyYW... ) Two more points: * Ideally the type of a parameter would depend on the parameter only, that is be independent of the result type. In cases where the result is based on a calculation it should be possible to pass in all kinds of types for the operands. For example passing 2.5d and 2f to a calculation expected to return Integer seems fine to me, and I would expect the result of (int) (2.5d * 2f) to be 5. * Hibernate is usually really good at this, too! It only seems to fail when I use an entity field in the calculation (which I wish I didn’t have to but that’s another discussion) Consider the following almost-identical queries: // Let test.intField be initialized to 2, int session.createQuery(""" UPDATE TestEntity test SET test.bigDecimalField = test.intField * ?1 """) .setParameter(1, BigDecimal.valueOf(2.5d)) .executeUpdate(); // Result: Parameter value [2.5] did not match expected type [BasicSqmPathSource(intField : Integer ) ] // Let passing same value (2, int ) as a query param instead of reading the entity field session.createQuery(""" UPDATE TestEntity test SET test.bigDecimalField = ?1 * ?2 """) .setParameter(1, 2) .setParameter(2, BigDecimal.valueOf(2.5d)) .executeUpdate(); // Result: Update successful, value of 5.00 confirmed in entity ( 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=EmailN... ) This message was sent by Atlassian Jira (v1001.0.0-SNAPSHOT#100233- sha1:f5b6255 )

2 years, 8 months

1
0
0 / 0

[JIRA] (HHH-16939) Optimistic and Pessimistic Force Increment Update Statements are not committed when using a batch

by Vincent Sourin (JIRA)

Vincent Sourin ( https://hibernate.atlassian.net/secure/ViewProfile.jspa?accountId=557058%... ) *commented* on HHH-16939 ( https://hibernate.atlassian.net/browse/HHH-16939?atlOrigin=eyJpIjoiZDQzOT... ) Re: Optimistic and Pessimistic Force Increment Update Statements are not committed when using a batch ( https://hibernate.atlassian.net/browse/HHH-16939?atlOrigin=eyJpIjoiZDQzOT... ) Same problem here with Quarkus 3.2.2.Final & Hibernate 6.2.6.Final ( https://hibernate.atlassian.net/browse/HHH-16939#add-comment?atlOrigin=ey... ) Add Comment ( https://hibernate.atlassian.net/browse/HHH-16939#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=EmailN... ) This message was sent by Atlassian Jira (v1001.0.0-SNAPSHOT#100233- sha1:f5b6255 )

2 years, 8 months

1
0
0 / 0

[JIRA] (HHH-16986) CoercionException caused by attempted coercion of query param to entity field type

by Gavin King (JIRA)

Gavin King ( https://hibernate.atlassian.net/secure/ViewProfile.jspa?accountId=557058%... ) *commented* on HHH-16986 ( https://hibernate.atlassian.net/browse/HHH-16986?atlOrigin=eyJpIjoiY2IyOT... ) Re: CoercionException caused by attempted coercion of query param to entity field type ( https://hibernate.atlassian.net/browse/HHH-16986?atlOrigin=eyJpIjoiY2IyOT... ) > > > > the other half are modifying queries on an entity where I’d imagine the > return type of the calculation should be known > > Right, that’s what I was alluding to when I said: > > > > there are some related cases where we probably could do better > > though I was thinking more of the case of such an expression occurring in a where clause. But it’s really not as simple as you imagine, since we can have quite complex expressions involving parameters and functions and operators and allowing things like this would mean not type checking the whole expression as soon as the expression involves a parameter and a numeric operator. That’s a bit nasty. And yes, of course we could make it work in a piecemeal way for some special cases. But that’s a bad way to design languages. I much prefer bright-line rules about what is allowed and what is disallowed. Otherwise you end up with Perl. So it’s simply unclear whether this is something we should even try to fix. (I need to talk it over with Steve.) > > > > I guess it might just have copied over the anticipated type of the operand > it does know ( test.intField ) to the operand it does not know. > > Right, that’s exactly what it does: it infers the parameter type from the other operand. This is the best it can do in general. What you’re asking the query compiler to do is an implicit numeric type promotion to a type it has no way of knowing. That’s asking for rather a lot. In general, it’s asking for the impossible. Now, one option which I’ve toyed with a bit is allowing the type of parameters to be declared explicitly, something like: select test.intField * BigDecimal?1 select test.intField * BigDecimal: name or: select test.intField * (?1 as BigDecimal) select test.intField * (: name as BigDecimal) or whatever. This would solve the problem completely. In the meantime, I don’t think the obvious workaround is that terrible: select cast(test.intField as BigDecimal) * ?1 This is just barely more verbose than the proposed new syntax (one extra token). Implicit type promotions can always be rewritten as explicit casts, so this workaround always works. ( 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=EmailN... ) This message was sent by Atlassian Jira (v1001.0.0-SNAPSHOT#100233- sha1:f5b6255 )

2 years, 8 months

1
0
0 / 0

[JIRA] (HBX-2557) Create 'org.hibernate.tool.hbm2x.*' exporter classes in the JBT bridge

by Koen Aers (JIRA)

2 years, 8 months

1
0
0 / 0

[JIRA] (HBX-2546) Extract the generic functionality from the experimental runtime plugin

by Koen Aers (JIRA)

2 years, 8 months

1
0
0 / 0

[JIRA] (HHH-16984) Disable use of arrays for batch and multi-loader on H2

by Sanne Grinovero (JIRA)

2 years, 8 months

1
0
0 / 0

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

hibernate-issues July 2023