[hibernate-dev] Native SQL Queries and Parameters

[Steve Ebersole]

On Mon, Jun 18, 2018, 2:44 AM 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.
>

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 <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
>