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
