Doing this with multiple parameters, especially if they're optional, makes for not only a lot more lines but lines that aren't contiguous.
To me, the core issue is that this optimization disregards my mapping configuration for certain hard-coded types. I will concede that mapping primitives through a custom UserType is unusual.
Perhaps if this inlining were performed later it could be advantageous for anything that winds up (after mapping) as an integer. Off the top of my head the biggest example here would be enumerations.
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
What I meant by "messy" is that something which would pretty much be one line:
criteria.where( .... );
becomes:
ParameterExpression<...> param = cb.parameter( ... );
criteria.where( ... );
...<other criteria building, sort, etc>...
query.setParameter( param, ... );
Doing this with multiple parameters, especially if they're optional, makes for not only a lot more lines but lines that aren't contiguous.
To me, the core issue is that this optimization disregards my mapping configuration for certain hard-coded types. I will concede that mapping primitives through a custom UserType is unusual.
Perhaps if this inlining were performed later it could be advantageous for anything that winds up (after mapping) as an integer. Off the top of my head the biggest example here would be enumerations.