Allowed parameter Java types

[sebersole]

Historically Hibernate allowed binding parameters with "mismatched" java types. E.g., given the legacy HQL Animal :

String qryString = 
        "select ... " +
        "from Animal a " + 
        "where a.bodyWeight > :weight"

Query qry = session.createQuery( qryString );
qry.setParameter( "weight", 1 );
...

#bodyWeight is defined as Float, but here we try to bind an Integer. Previous versions allowed this. At the moment, on 6.0, this fails because we are expecting a Float, not an Integer.

We had discussed this previously and decided to not allow that, but I believe it was just on Zulip. Wanted to document this decision for posterity.

This new behavior is consistent with loading an entity. Assuming an entity has a Long id, session.get( TheEntity.class, 1 ) will fail even on older versions.

[gavinking]

I think this is perfectly fine if we do believe that the code you've just shown is "actually bad".

OTOH, I also think it's fine to treat a "small" number of numeric types specially. Almost all programming languages have hardcoded implicit conversions between numeric types, and I do actually thinks that's reasonable.

As an example, I would find it very convenient if Hibernate implicitly converted Integer to BigInteger and Double or Float to BigDecimal.

But I would distinguish this from anything more open-ended. I think numeric types are a special case.

[gavinking]

Are you sure? Im pretty sure they're equivalent, according to the Javadoc of valueOf().

[yrodiere]

new BigDecimal("2.168454845484461448") will work for arbitrary precision. BigDecimal.valueOf(someDouble) will only work for numbers that can be acurately encoded as doubles.

And as you know:

• the compiler will accept double literals even if they cannot be encoded accurately as doubles; they will be truncated (kind of).
• Double.parseDouble will also accept input with arbitrary precision and truncate it to fit into a double.

If a user ends up with a double when they are passing parameters to their query, they probably used one of the above at some point. And in all but the most trivial cases, if you're dealing with BigDecimal in your database, that's bad practice.

[gavinking]

Well, OK, but I don't think there's anything at all we can reasonably do to protect users from that.

If the user already has a double (that's coming from wherever ... I don't know, users don't always have control of where their data comes from), I don't see what extra safety we're really gaining by asking them to perform the conversion to BigDecimal explicitly rather than doing it for them implicitly. The actual conversion that valueOf() does is exact (if I understand correctly). And that's all we would be doing.

It's pretty much on them to make sure the double they pass in isn't rubbish. We can't help them not have rubbish doubles in their program, AFAICS. By the time we see this double, the damage you're describing has already been done.

Now, OTOH, if BigDecimal.valueOf() can't be trusted to perform a conversion exactly, then I agree, it should be an explicit operation.

[yrodiere]

I don't think there's anything at all we can reasonably do to protect users from that

We cannot solve their problem. We cannot prevent it from happening. But I don't think we should hide the problem under the carpet by automatically converting the value. Because we know something is wrong.

IMO it's similar to saying "I will add a * operator between double and String in my programming language, converting the string to a double implicitly because it's convenient". Yes, it can be convenient. Yes, there may be (very) limited instances, most likely in demo code, where this is legitimate. But I don't think it's a good idea, because it encourages bad practices, and can hide existing problems within the user's code.

By the time we see this double, the damage you're describing has already been done.

Indeed. I am hoping that seeing a conversion error would lead the user to think twice about what's going on.

[gavinking]

Yeah, I mean, fine, OK, I see your point, and in a different context it's indeed the sort of thing I would argue. I'm just not convinced it's a strong enough consideration in this particular case.

But whatever, honestly I don't care that much about this particular conversion. I'm more concerned about e.g. Integer -> BigDecimal, since that lets me write 2 instead of something much uglier.

[beikov]

What do you mean by "historically"? I just tried this example with the current state of main i.e. 5.5.0-SNAPSHOT and it does not work. I get:

java.lang.IllegalArgumentException: Parameter value [1] did not match expected type [java.lang.Float (n/a)]

	at org.hibernate.query.spi.QueryParameterBindingValidator.validate(QueryParameterBindingValidator.java:54)
	at org.hibernate.query.spi.QueryParameterBindingValidator.validate(QueryParameterBindingValidator.java:27)
	at org.hibernate.query.internal.QueryParameterBindingImpl.validate(QueryParameterBindingImpl.java:90)
	at org.hibernate.query.internal.QueryParameterBindingImpl.setBindValue(QueryParameterBindingImpl.java:55)
	at org.hibernate.query.internal.AbstractProducedQuery.setParameter(AbstractProducedQuery.java:501)
	at org.hibernate.query.internal.AbstractProducedQuery.setParameter(AbstractProducedQuery.java:122)

[gavinking]

@sebersole can this be closed now?