On Mon, Jun 18, 2018, 2:44 AM Yoann Rodiere <yrodiere(a)redhat.com&gt; wrote: 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/29c6861ac89c91ea03c4b9... > <https://github.com/hibernate/hibernate-search/blob/master/jsr352/core/src... > <https://github.com/hibernate/hibernate-search/blob/29c6861ac89c91ea03c4b9... > On Sat, 16 Jun 2018 at 20:20 Steve Ebersole <steve(a)hibernate.org&gt; 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(a)lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/hibernate-dev >> -- > Yoann Rodiere > yoann(a)hibernate.org / yrodiere(a)redhat.com > Software Engineer > Hibernate NoORM team