HHH-20021 simple fix #11518
HHH-20021 simple fix #11518
Conversation
| // Instead of doing this, it's also possible to provoke the bug by binding another calendar parameter | ||
| typeConfiguration.getBasicTypeRegistry().getRegisteredType( "java.util.GregorianCalendar" ); | ||
| scope.inTransaction( | ||
| entityManager -> { | ||
| Query query = entityManager.createQuery("from DataPoint dp where my_function(:cal) = 1") | ||
| .setParameter("cal", calendar, TemporalType.TIMESTAMP); | ||
| query.getResultList(); | ||
| } | ||
| ); |
There was a problem hiding this comment.
With the change to use typeConfiguration.getBasicTypeRegistry().getRegisteredType( "java.util.GregorianCalendar" ); instead of typeConfiguration.getBasicTypeForJavaType( GregorianCalendar.class );, the test is not reproducing the bug anymore. You can also use this to see that your change does not fix the problem:
| // Instead of doing this, it's also possible to provoke the bug by binding another calendar parameter | |
| typeConfiguration.getBasicTypeRegistry().getRegisteredType( "java.util.GregorianCalendar" ); | |
| scope.inTransaction( | |
| entityManager -> { | |
| Query query = entityManager.createQuery("from DataPoint dp where my_function(:cal) = 1") | |
| .setParameter("cal", calendar, TemporalType.TIMESTAMP); | |
| query.getResultList(); | |
| } | |
| ); | |
| scope.inTransaction( | |
| entityManager -> { | |
| Query query = entityManager.createQuery("from DataPoint dp where my_function(:cal) = 1") | |
| .setParameter("cal", calendar, TemporalType.TIMESTAMP); | |
| query.getResultList(); | |
| } | |
| ); | |
| scope.inTransaction( | |
| entityManager -> { | |
| Query query = entityManager.createQuery("from DataPoint dp where my_function(:cal) = 1") | |
| .setParameter("cal", calendar, TemporalType.TIMESTAMP); | |
| query.getResultList(); | |
| } | |
| ); |
There was a problem hiding this comment.
With the change to use
typeConfiguration.getBasicTypeRegistry().getRegisteredType( "java.util.GregorianCalendar" );instead oftypeConfiguration.getBasicTypeForJavaType( GregorianCalendar.class );the test is not reproducing the bug anymore.
Of course. I did that on purpose. Because GregorianCalendar.class is clearly not a legitimate argument of that method (there is no JavaType<GregorianCalendar> in the registry) and so it SHOULD throw for GregorianCalendar.class. It's correct for it to throw.
You can also use this to see that your change does not fix the problem:
You must have intended to type something else there. All your suggestion does is dupe the first query.
There was a problem hiding this comment.
@beikov Do you understand the concept here? That we should be distinguishing Class keys from String keys and treating them differently, according to:
Class<T>->JavaType<T>(both invariant types)String->JavaType<?>(wildcarded type)
I didn't FTR, claim that this trivial change completely fixes the mixup between those two things that's going on in the code currently. Just that it conceptually demonstrates how to fix this in a well-defined way, instead of by trying to hack around what the type system is asking is to see.
cc @beikov
By submitting this pull request, I confirm that my contribution is made under the terms of the Apache 2.0 license
and can be relicensed under the terms of the LGPL v2.1 license in the future at the maintainers' discretion.
For more information on licensing, please check here.
https://hibernate.atlassian.net/browse/HHH-20021