[hibernate-dev] Native SQL Queries and Parameters

[Yoann Rodiere]

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