Re: [hibernate-dev] Query#iterate

2017-01-28 Thread andrea boriero 
+1 to remove

On 28 Jan 2017 20:44, "Chris Cranford"  wrote:

> +1 to remove as well
>
>
> On 01/27/2017 01:50 PM, Sanne Grinovero wrote:
> > +1 to remove
> >
> > On 27 January 2017 at 18:34, Vlad Mihalcea 
> wrote:
> >> I'm for removing it even if it didn't complicate the query parser.
> >>
> >> Vlad
> >>
> >> On Fri, Jan 27, 2017 at 8:26 PM, Steve Ebersole 
> wrote:
> >>
> >>> Because the behavior is also fundamentally questionable.
> >>>
> >>> On Fri, Jan 27, 2017 at 12:17 PM Christian Beikov <
> >>> christian.bei...@gmail.com> wrote:
> >>>
>  I'm sorry, I apparently confused iterate() with scroll() then, so
> forget
>  what I wrote before ^^
> 
>  In face of that new info, I actually don't know of any actual users.
> >>> After
>  thinking a bit about it, why not make that behavior configurable via
>  setProperty and drop that method?
> 
> 
>  Am 27.01.2017 um 19:01 schrieb Steve Ebersole:
> 
>  On Fri, Jan 27, 2017 at 9:51 AM Christian Beikov <
>  christian.bei...@gmail.com> wrote:
> 
>  I just know of people that are using iterate() now for efficient
>  incremental processing, but I guess any other approach(streams maybe?)
>  to do incremental processing would be good enough for these users.
> 
> 
>  ScrollableResults do not meet that need?
> 
> 
> 
>  Unfortunately I don't know what a shallow query is or what the
>  implication on the query or the processing of being shallow are.
> 
> 
>  Just what I said before.  "shallow" is simply a boolean flag that is
> part
>  of the translator.  It is set to true when the translation is
> triggered
>  from Query#iterate.  When the translation is triggered from
> Query#list or
>  Query#scroll it is set to false.
> 
> 
> 
>  I guess this has to do with how row processing is done?
> 
> 
>  The main thing is effects is the SQL we render.  For "entity returns"
> it
>  simply selects the ids and we expect to then load them (immediately!)
> by
>  that id (N+1).  Its usefulness is actually VERY limited in scope as it
>  actually performs horrendously in, what, 95-99% of use cases?
> 
>  Interestingly it really does not have much effect on "row processing".
> 
> 
> 
> >>> ___
> >>> hibernate-dev mailing list
> >>> hibernate-dev@lists.jboss.org
> >>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
> >>>
> >> ___
> >> hibernate-dev mailing list
> >> hibernate-dev@lists.jboss.org
> >> https://lists.jboss.org/mailman/listinfo/hibernate-dev
> > ___
> > hibernate-dev mailing list
> > hibernate-dev@lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/hibernate-dev
>
> ___
> hibernate-dev mailing list
> hibernate-dev@lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>
___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev

Re: [hibernate-dev] Extended KEY expression support

2017-01-28 Thread Chris Cranford 
My thoughts


On 01/28/2017 06:00 AM, Christian Beikov wrote:
> I created an issue for this feature:
> https://hibernate.atlassian.net/browse/HHH-11433
>
>
> Am 27.01.2017 um 23:58 schrieb Steve Ebersole
>> I personally would vote to *not* make this change in 5.x even in terms
>> of making it configurable.  The grammar there is fugly enough already
>> and this is the kind of thing (especially making branches of it
>> configurable) that takes that fugliness to a new level.
> I gave that another thought and don't think that requiring the user to
> do a separate join is a good idea anymore. We can actually infer if a
> join is required and when using the ANSI parenthesis join syntax the
> join type does not really matter. If we stick to the join rendering
> style we have, we should just use the collection tables join type.
>
> Do you think it makes sense to implement support for "JOIN
> KEY(m).association" in 5.2 or just leave it as it is? I would implement
> that if you give your ok.
>
> What do you think about all that so far?
>
I'd say we likely shouldn't be putting significant effort into adding 
**new features*** *into 5.2.  I'd recommend adding it into the 6.0 
branch and if/when we decide to consider a 5.3 branch release as a 
further stepping stone to 6.0, perhaps we back-port this feature to that 
branch if the team feels its relevant to do so.

But that's just my perspective :).

Chris
___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev

Re: [hibernate-dev] Query#iterate

2017-01-28 Thread Chris Cranford 
+1 to remove as well


On 01/27/2017 01:50 PM, Sanne Grinovero wrote:
> +1 to remove
>
> On 27 January 2017 at 18:34, Vlad Mihalcea  wrote:
>> I'm for removing it even if it didn't complicate the query parser.
>>
>> Vlad
>>
>> On Fri, Jan 27, 2017 at 8:26 PM, Steve Ebersole  wrote:
>>
>>> Because the behavior is also fundamentally questionable.
>>>
>>> On Fri, Jan 27, 2017 at 12:17 PM Christian Beikov <
>>> christian.bei...@gmail.com> wrote:
>>>
 I'm sorry, I apparently confused iterate() with scroll() then, so forget
 what I wrote before ^^

 In face of that new info, I actually don't know of any actual users.
>>> After
 thinking a bit about it, why not make that behavior configurable via
 setProperty and drop that method?


 Am 27.01.2017 um 19:01 schrieb Steve Ebersole:

 On Fri, Jan 27, 2017 at 9:51 AM Christian Beikov <
 christian.bei...@gmail.com> wrote:

 I just know of people that are using iterate() now for efficient
 incremental processing, but I guess any other approach(streams maybe?)
 to do incremental processing would be good enough for these users.


 ScrollableResults do not meet that need?



 Unfortunately I don't know what a shallow query is or what the
 implication on the query or the processing of being shallow are.


 Just what I said before.  "shallow" is simply a boolean flag that is part
 of the translator.  It is set to true when the translation is triggered
 from Query#iterate.  When the translation is triggered from Query#list or
 Query#scroll it is set to false.



 I guess this has to do with how row processing is done?


 The main thing is effects is the SQL we render.  For "entity returns" it
 simply selects the ids and we expect to then load them (immediately!) by
 that id (N+1).  Its usefulness is actually VERY limited in scope as it
 actually performs horrendously in, what, 95-99% of use cases?

 Interestingly it really does not have much effect on "row processing".



>>> ___
>>> hibernate-dev mailing list
>>> hibernate-dev@lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>>>
>> ___
>> hibernate-dev mailing list
>> hibernate-dev@lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
> ___
> hibernate-dev mailing list
> hibernate-dev@lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev

___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev

Re: [hibernate-dev] Extended KEY expression support

2017-01-28 Thread Christian Beikov 
I created an issue for this feature: 
https://hibernate.atlassian.net/browse/HHH-11433

If we agree to render "domain joins" that involve multiple tables with 
the ANSI SQL parenthesis join syntax, we can actually even "ignore" the 
join types for key and value tables. That would make things like 
referring to subtype properties in an ON clause also a lot easier.

Here a quick example:

@Entity class Entity{ Map map; }
@Entity @Inheritance(JOINED) class A{ ... }
@Entity class B extends A { String propertyB; }
@Entity class C extends A { String propertyC; }

@Entity @Inheritance(JOINED) class X { String propertyX; }
@Entity class Y { String propertyY; }
@Entity class Z { String propertyZ; }

SELECT e.id, KEY(m), VALUE(m)
FROM Entity e
LEFT JOIN e.map m
   ON KEY(m).propertyX >  0 AND TREAT(KEY(m) AS Y).propertyY = TREAT(m 
AS B).propertyB
   OR KEY(m).propertyX <= 0 AND TREAT(KEY(m) AS Z).propertyZ = TREAT(m 
AS C).propertyC

That would render roughly like

SELECT ...
FROM table_entity e
LEFT JOIN (
   table_map m
   JOIN (
 table_x x
 LEFT JOIN table_y y ON x.id = y.id
 LEFT JOIN table_z z ON x.id = z.id
   ) ON m.key = x.id
   JOIN (
 table_a a
 LEFT JOIN table_b b ON a.id = b.id
 LEFT JOIN table_c c ON a.id = c.id
   ) ON m.value = a.id
) m ON m.e_id = e.id AND (
  x.property_x >  0 AND y.property_y = b.property_b
   OR x.property_x <= 0 AND z.property_z = c.property_c
)

I guess the concept of the parenthesis join fits the table group idea?

Am 27.01.2017 um 23:58 schrieb Steve Ebersole
>
> A further change to that would be to not generate the implicit key
> table join anymore but require the user to do the join explicitly.
> Since
> that would break backwards compatibility, I'd like to make that
> behavior
> configurable and of course, by default it will generate the
> implicit key
> join to maintain backwards compatibility. I also propose to switch the
> default in 6.0 so that the join is not generate anymore.
>
>
> I personally would vote to *not* make this change in 5.x even in terms 
> of making it configurable.  The grammar there is fugly enough already 
> and this is the kind of thing (especially making branches of it 
> configurable) that takes that fugliness to a new level.

I gave that another thought and don't think that requiring the user to 
do a separate join is a good idea anymore. We can actually infer if a 
join is required and when using the ANSI parenthesis join syntax the 
join type does not really matter. If we stick to the join rendering 
style we have, we should just use the collection tables join type.

Do you think it makes sense to implement support for "JOIN 
KEY(m).association" in 5.2 or just leave it as it is? I would implement 
that if you give your ok.

What do you think about all that so far?
___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev