Just to be clear, we're not just talking actual hard-coded-in-Java literals here, it's a matter of all values (T) supplied to various CriteriaBuilder methods. E.g. CriteriaBuilder.equal().
Secondly, the irregular behavior isn't a matter of inlining values or not, that doesn't change the results of the query. It's a matter of bypassing user-defined mapping when the type is numeric. At worst, this will yield incorrect results; at best it will result in broken statements (depending on if the database will implicitly convert the literal to the actual column type).
Since JPA has no provisions for custom mappings, it comes down to whether Hibernate considers it valid to supply user-defined mappings on these types:
If yes, then this API behaves irregularly (it honors my mappings on all other types).
If not, then I apologize if this has already been documented, but wonder why there isn't at least MappingExceptions so I find out right away exactly what I'm doing wrong.
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
Just to be clear, we're not just talking actual hard-coded-in-Java literals here, it's a matter of all values (T) supplied to various CriteriaBuilder methods. E.g. CriteriaBuilder.equal().
Secondly, the irregular behavior isn't a matter of inlining values or not, that doesn't change the results of the query. It's a matter of bypassing user-defined mapping when the type is numeric. At worst, this will yield incorrect results; at best it will result in broken statements (depending on if the database will implicitly convert the literal to the actual column type).
Since JPA has no provisions for custom mappings, it comes down to whether Hibernate considers it valid to supply user-defined mappings on these types: