[hibernate-dev] Native SQL Queries and Parameters

[andrea boriero]

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 <yoann at 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 <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.
> >
> > 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 <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
> >
> --
> Yoann Rodiere
> yoann at hibernate.org / yrodiere at redhat.com
> Software Engineer
> Hibernate NoORM team
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>