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.
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. 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... [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 Mon, 18 Jun 2018 at 09:44 Yoann Rodiere <yrodi...@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. > > 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. > > 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... > > [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 <st...@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@lists.jboss.org >> https://lists.jboss.org/mailman/listinfo/hibernate-dev >> > -- > Yoann Rodiere > yo...@hibernate.org / yrodi...@redhat.com > Software Engineer > Hibernate NoORM team > -- Yoann Rodiere yo...@hibernate.org / yrodi...@redhat.com Software Engineer Hibernate NoORM team _______________________________________________ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev
