[hibernate-dev] Native SQL Queries and Parameters

Steve Ebersole steve at hibernate.org
Mon Jun 18 08:16:29 EDT 2018

On Mon, Jun 18, 2018, 2:44 AM Yoann Rodiere <yrodiere at redhat.com> wrote:

> If by "basic types" you mean *all* basic types, including user-defined
> ones, I think it would make sense. Otherwise it sounds a bit limiting.

In 6.0 "user-defined type" means a very different thing generally speaking.
But I mean any BasicType, which may be a Hibernate class or a user class.


> There's the case of embedded IDs that might be considered as an exception,
> but I'm not sure there's a compelling reason to do so.

But this is my point.  We can support composite parameters here.  The
question really is whether we want to.  In SQL there is no construct like
`(col1, col2) " ?` regardless of whether col1 and col2 are PK columns or
normal columns.

Really what I am asking is how closely we want native queries to look, feel
and work like a SQL query.  Otherwise it's not really "native"

> By the way... it's not native queries, but it illustrates the challenges
> of supporting such composite types. There is currently some support for
> composite types in ORM 5, in org.hibernate.criterion.Order#toSqlString,
> Restrictions.gt, Restrictions.ge, etc. But restrictions are a bit buggy, in
> a way that we had to circumvent in Hibernate Search [1]. In short they do
> not implement restrictions lexicographically, resulting in
> Restrictions.disjunction( Restrictions.gt( "myCompositeProperty", someValue
> ), Restrictions.le( "myCompositeProperty", someValue ) ) not matching all
> records, which may be counter-intuitive to some.
> Would it make sense for me to open a ticket? I'm not sure that's the kind
> of behavior one can change in 5, but maybe in a major such as 6...

You are talking about Hibernate's legacy criteria API which has been
deprecated for many years now and is already gone in 6.  So no, I don't
want to see Jiras for that 😉

> [1] *https://github.com/hibernate/hibernate-search/blob/29c6861ac89c91ea03c4b97cd4e6225d10bb7464/jsr352/core/src/main/java/org/hibernate/search/
> <https://github.com/hibernate/hibernate-search/blob/29c6861ac89c91ea03c4b97cd4e6225d10bb7464/jsr352/core/src/main/java/org/hibernate/search/jsr352/massindexing/impl/util/CompositeIdOrder.java#L106>https://github.com/hibernate/hibernate-search/blob/master/jsr352/core/src/main/java/org/hibernate/search/jsr352/massindexing/impl/util/CompositeIdOrder.java#L107
> <https://github.com/hibernate/hibernate-search/blob/master/jsr352/core/src/main/java/org/hibernate/search/jsr352/massindexing/impl/util/CompositeIdOrder.java#L107>**jsr352/massindexing/impl/util/CompositeIdOrder.java#L106
> <https://github.com/hibernate/hibernate-search/blob/29c6861ac89c91ea03c4b97cd4e6225d10bb7464/jsr352/core/src/main/java/org/hibernate/search/jsr352/massindexing/impl/util/CompositeIdOrder.java#L106>*
> On Sat, 16 Jun 2018 at 20:20 Steve Ebersole <steve at hibernate.org> wrote:
>> While working on 6.0 I am wondering whether it makes sense to support
>> parameters of anything other than basic types.  Personally I am thinking
>> not, but wanted to get other's opinions.
>> The idea being that neither SQL nor JDBC define support for bind
>> parameters
>> of multiple values.  So expecting to bind non-simple values is not
>> strictly
>> "native SQL" support.
> _______________________________________________
>> hibernate-dev mailing list
>> hibernate-dev at lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
> --
> Yoann Rodiere
> yoann at hibernate.org / yrodiere at redhat.com
> Software Engineer
> Hibernate NoORM team

More information about the hibernate-dev mailing list