org.hibernate.query.Query typed parameter recommendations: setParameter(String, Object) vs. setParameter(String, Object, Type)


#1

Hello,

I’m working to remove some deprecation warnings related with typed query parameters , i.e., regarding to the usage of methods like setDate, setBigDecimal of org.hibernate.query.Query class.

According to the documentation, to replace that kind of methods I can choose either setParameter(String, Object) or setParameter(String, Object, Type).

Which method would you recommend to use? Is there any performance implications of using the method where the type is not specified? Is there any scenario where one method should be preferred to the other one?

Thank you!

Regards,
Carlos.


#2

On the vast majority of cases, using the setParameter(String, Object) is the way to go.

The setParameter(String, Object, Type) is useful when you are binding a custom type that was not added to the Type registry.

Is there any performance implications of using the method where the type is not specified?

For JPQL queries, the parameter metadata is provided during query parser phase, so the type is already known prior to binding it.

For native SQL queries, when using setParameter(String, Object) the type must be resolved like this:

typeResolver.resolveParameterBindType( value );

which boils down to getting the Typevalue from a Map. Therefore, it’s not something you should worry about. Most often, data access performance is driven by the effectiveness of the underlying queries as well as the amount of data you are fetching.


#3

Hello,

ok, great. I’ll proceed then with setParameter(String, Object).

Thank you for the quick response.


#4

High-Performance, right? :grinning:


#5

yes :grin: :grin: performance is one of the main topics we should always have in mind in our developments…and specially when upgrading the stack (Hibernate in my case…)

Besides, I noticed that the implementation of the deprecated methods (like setDate) is specifying the type, and I was a bit concerned if it was better whether use it or not…