On Mon, Jun 18, 2018, 2:44 AM 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. > 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 <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 > _______________________________________________ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev
