Re: [hibernate-dev] Native SQL Queries and Parameters

2018-06-18 Thread Steve Ebersole 
On Mon, Jun 18, 2018, 2:44 AM Yoann Rodiere  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/master/jsr352/core/src/main/java/org/hibernate/search/jsr352/massindexing/impl/util/CompositeIdOrder.java#L107
> **jsr352/massindexing/impl/util/CompositeIdOrder.java#L106
> *
>
>
> On Sat, 16 Jun 2018 at 20:20 Steve Ebersole  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

Re: [hibernate-dev] Native SQL Queries and Parameters

2018-06-18 Thread 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  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  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  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
>

Re: [hibernate-dev] Native SQL Queries and Parameters

2018-06-18 Thread 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/master/jsr352/core/src/main/java/org/hibernate/search/jsr352/massindexing/impl/util/CompositeIdOrder.java#L107
**jsr352/massindexing/impl/util/CompositeIdOrder.java#L106
*


On Mon, 18 Jun 2018 at 09:44 Yoann Rodiere  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/master/jsr352/core/src/main/java/org/hibernate/search/jsr352/massindexing/impl/util/CompositeIdOrder.java#L107
> **jsr352/massindexing/impl/util/CompositeIdOrder.java#L106
> *
>
>
> On Sat, 16 Jun 2018 at 20:20 Steve Ebersole  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