Perhaps it is a common "problem", but one that stems from an interface defined by JSR-220. Guess what, Hibernate does not control the definition of that interface. Thus, whether you choose to believe it or not, such comments need to be directed at previously mentioned mailing list.
As for your "example", you are completely wrong. Hibernate can in fact determine the appropriate type, because the parameter is compared to a boolean constant. Not sure if you are aware but I changed the way in which Hibernate "guesses" the type of parameter values a few months ago. Before, it used to inspect the incoming parameter value to make that determination. That is no longer the case. Instead, it now uses the parsed structure of the query to make that guess. For example, in your example, ":p" is used at one point in a comparison to a boolean constant (":p = true"), thus Hibernate knows to expect ":p" to be of boolean type. Who said Address was an entity? It could very well be a component. It could very well be a simple type even! The important point you are missing is that it is a non-jdk class, and thus there is very little that can be assumed about it. Why do you think setParameter(int, int) is better that setInteger(int, int)? I don't get it. You say something about binding null values later on, but that's rubbish since your setInteger(int, int) would obviously not work for null values either. Because it has the same name and thus is "overloaded"? I guess; I just don't see the clear benefit there. And I need to see a *clear* benefit before I go changing APIs that people have been using for over two years... -----Original Message----- From: Juraj Burian [mailto:[EMAIL PROTECTED] Sent: Tuesday, May 23, 2006 8:02 AM To: Steve Ebersole Cc: hibernate-devel@lists.sourceforge.net Subject: Re: [Hibernate] weak javax.persistence.Query interface Steve Ebersole wrote: >I think you are looking for [EMAIL PROTECTED] > May be, but in my opinion it is a common problem. >But kind of hard >for them to change the persistence spec to add "type" to the >setParameter() methods when JPA does not even have a notion of a "type". > > try realize select like: from X where ((:p is NULL) AND ( ....)) OR ((:p = true) AND(....)) OR((:p = false) AND(...)) p is a Boolean or null. Current (Hibernate) implementation of javax.persistence.Query can't create valid SQL select, because "type" is lost .... >So in your Hibernate request(s), then how do you propose that we allow >users to bind parameters of user-defined type? Obviously >Query.setParameter(String, Address) is not an option. No Hibernate's >API is fine, thank you. > > Discusion was only about NullableTypes, NOT about entities. Hibernate have pair of methods defined: public Query setEntity(int position, Object val) & public Query setEntity(String name, Object val). Hibernate API is ok, but I mean that nullable types like Long, Numeric, Integer, Boolean .... need setParameter methods. it's a nice extension mothing more (in context of hibernate.Query). You must call: public Query setParameter(int position, Object val, Type type) if you want put null value correctly. >-----Original Message----- >From: [EMAIL PROTECTED] >[mailto:[EMAIL PROTECTED] On Behalf Of Juraj >Burian >Sent: Tuesday, May 23, 2006 6:40 AM >To: hibernate-devel@lists.sourceforge.net >Subject: [Hibernate] weak javax.persistence.Query interface > >Problem definition: >javax.persistence.Query interface has not defined "typed" setPrarameter >methods. >There exists valid queries that can't be parametrized properly via >methods in javax.persistence.Query. > >details: >in java.sql.PreparedStatement exists only two method for setting null >values, namely setNull(int parameterIndex, int sqlType) && setNull(int >parameterIndex, int sqlType, String typeName). >If we need pass valid null value into the query, these methods must be >used. >In hibernate Query interface (org.hibernate.Query) exists method Query >setParameter(int position, Object val, Type type) that solve this >problem. > >So, we need define more rich API in javax.persistence.Query interface to >pass "types" into a Query. >probably we need add methods : >public Query setParameter(int position, Type value) >public Query setParameter(String name, Type value), where Type is from >Long, Boolean ...., in general NullableType see >org.hibernate.type.NullableType. > >Problem is that fixes in EJB 3 specification are necessary. :-( > >remarks: >org.hibernate.Query is not well object oriented. >I mean that methods like setInteger, setBoolean ... should be "marked" >obsolete and should be replaced with methods setParamater(int, >int)/setParameter(String, int), setParameter(int, >boolean)/setParameter(String boolean) ... in future releases. > > >best regards >JuBu > >p.s. sorry for my weak English > > > > > > > > > > > > > > > > > >||| >| >||| >| > > > > > > > > >------------------------------------------------------- >Using Tomcat but need to do more? Need to support web services, >security? >Get stuff done quickly with pre-integrated technology to make your job >easier >Download IBM WebSphere Application Server v.1.0.1 based on Apache >Geronimo >http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=12164 2 >_______________________________________________ >hibernate-devel mailing list >hibernate-devel@lists.sourceforge.net >https://lists.sourceforge.net/lists/listinfo/hibernate-devel > > > > ------------------------------------------------------- Using Tomcat but need to do more? Need to support web services, security? Get stuff done quickly with pre-integrated technology to make your job easier Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo http://sel.as-us.falkag.net/sel?cmd=lnk&kid0709&bid&3057&dat1642 _______________________________________________ hibernate-devel mailing list hibernate-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/hibernate-devel