On Mon, Jun 18, 2018, 2:44 AM Yoann Rodiere <yrodiere(a)redhat.com> wrote:
If by "basic types" you mean *all* basic types, including
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
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 . In short they do
> not implement restrictions lexicographically, resulting in
> Restrictions.disjunction( Restrictions.gt( "myCompositeProperty",
> ), 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 😉
> On Sat, 16 Jun 2018 at 20:20
Steve Ebersole <steve(a)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
>> of multiple values. So expecting to bind non-simple values is not
>> "native SQL" support.
>> hibernate-dev mailing list
> Yoann Rodiere
> yoann(a)hibernate.org / yrodiere(a)redhat.com
> Software Engineer
> Hibernate NoORM team