Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

HibernateTemplate query methods that support UserTypes [SPR-1159] #5861

Closed
spring-issuemaster opened this issue Jul 20, 2005 · 1 comment
Closed

Comments

@spring-issuemaster
Copy link
Collaborator

@spring-issuemaster spring-issuemaster commented Jul 20, 2005

Scott Clasen opened SPR-1159 and commented

Spring has no way of knowing what Hibernate Types to use in HibernateQueries, so if you attempt to use any of the find* methods in the template, and you are using a Hibernate UserType/CustomType(s) as query parameters, Spring/Hibernate will not be able to guess the type correctly.

It took me a while to figure out that you need to use a HibernateCallback to call the hibernate Query.setParamater(name, value, Type)

I would suggest adding some methods to the HibernateTemplate that support UserTypes, like..

findByNamedQuery(String queryName, Object value, org.hibernate.type.Type type)

findByNamedQuery(String queryName, Object[] values, org.hibernate.type.Type[] types)

Let me know if you would like me to submit a patch..


Affects: 1.2.2

@spring-issuemaster
Copy link
Collaborator Author

@spring-issuemaster spring-issuemaster commented Jul 20, 2005

Juergen Hoeller commented

Well, I would actually recommend to implement a HibernateCallback for such cases. HibernateTemplate's should only cover typical cases, not necessarily all cases that an application might need. For such advanced parameter setting, the Hibernate Query API is probably nicer to use than any flattened HibernateTemplate convenience operation could be...

We actually have convenience operations on the HibernateTemplate for Hibernate 2.1. We've not ported those to the HibernateTemplate for Hibernate3 because there are quite a lot of new operations exposed there, and we wanted to keep the total number of convenience operations down. After all, an anonymous inner-class HibernateCallback is a pretty straightforward thing as well...

Juergen

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
2 participants
You can’t perform that action at this time.