for native SQL I think it makes sense to only support basic types for parameters binding.
On Mon, 18 Jun 2018 at 08:45, Yoann Rodiere <yo...@hibernate.org> 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 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 > _______________________________________________ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev
