8:42 a.m.
I know I started a discussion of this somewhere with some of you, but I
cannot find it anymore.
I had suggested we consider getting rid of this Query#iterate method. I
just wanted to get everyone's opinions of this. Specifically, getting of
it in 6.0.
If anyone has dug much into the current Antlr 2 based parser you will be
familiar with this idea of shallow versus non-shallow queries. That is
where this comes into play. Query#iterate is a shallow query
(shallow=true). All other queries are non-shallow.
There are quite a few internal reasons to simply drop that method and get
rid of the idea of this shallow flag. I am happy to discuss these reasons
for those interested and that do not know.
But obviously we should not be getting rid of things just because of
"internal complications" if they are used by many users. I cannot speak to
whether any users use this, let alone how many.
Thoughts?
9:50 a.m.
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.
Unfortunately I don't know what a shallow query is or what the
implication on the query or the processing of being shallow are.
I guess this has to do with how row processing is done? I can imagine
that this complicates the implementation, but really, there are users
out there which rely on the performance model of that.
Am 27.01.2017 um 15:42 schrieb Steve Ebersole:
I know I started a discussion of this somewhere with some of you, but
I
cannot find it anymore.
I had suggested we consider getting rid of this Query#iterate method. I
just wanted to get everyone's opinions of this. Specifically, getting of
it in 6.0.
If anyone has dug much into the current Antlr 2 based parser you will be
familiar with this idea of shallow versus non-shallow queries. That is
where this comes into play. Query#iterate is a shallow query
(shallow=true). All other queries are non-shallow.
There are quite a few internal reasons to simply drop that method and get
rid of the idea of this shallow flag. I am happy to discuss these reasons
for those interested and that do not know.
But obviously we should not be getting rid of things just because of
"internal complications" if they are used by many users. I cannot speak to
whether any users use this, let alone how many.
Thoughts?
_______________________________________________
hibernate-dev mailing list
hibernate-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev
11:39 a.m.
I would not bother too much about iterate since it can be easily emulated
with an entity query.
If I recall correctly, Query#iterate does something like this:
select e.id
from Entity e
where condition
and for every identifier we can load the entity from the 2nd-level cache
instead of loading it from the DB.
Now, if the entities are not already cached, it will be a disaster if N is
fairly large.
For this reason, I think we should deprecate it and remove it anyway.
Vlad
On Fri, Jan 27, 2017 at 5:50 PM, Christian Beikov <
christian.beikov(a)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.
Unfortunately I don't know what a shallow query is or what the
implication on the query or the processing of being shallow are.
I guess this has to do with how row processing is done? I can imagine
that this complicates the implementation, but really, there are users
out there which rely on the performance model of that.
Am 27.01.2017 um 15:42 schrieb Steve Ebersole:
> I know I started a discussion of this somewhere with some of you, but I
> cannot find it anymore.
>
> I had suggested we consider getting rid of this Query#iterate method. I
> just wanted to get everyone's opinions of this. Specifically, getting of
> it in 6.0.
>
> If anyone has dug much into the current Antlr 2 based parser you will be
> familiar with this idea of shallow versus non-shallow queries. That is
> where this comes into play. Query#iterate is a shallow query
> (shallow=true). All other queries are non-shallow.
>
> There are quite a few internal reasons to simply drop that method and get
> rid of the idea of this shallow flag. I am happy to discuss these
reasons
> for those interested and that do not know.
>
> But obviously we should not be getting rid of things just because of
> "internal complications" if they are used by many users. I cannot speak
to
> whether any users use this, let alone how many.
>
> Thoughts?
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev
_______________________________________________
hibernate-dev mailing list
hibernate-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev
12:01 p.m.
On Fri, Jan 27, 2017 at 9:51 AM Christian Beikov <christian.beikov(a)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".
12:17 p.m.
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.beikov(a)gmail.com <mailto:christian.beikov@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".
12:26 p.m.
Because the behavior is also fundamentally questionable.
On Fri, Jan 27, 2017 at 12:17 PM Christian Beikov <
christian.beikov(a)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.beikov(a)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".
12:34 p.m.
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 <steve(a)hibernate.org> wrote:
Because the behavior is also fundamentally questionable.
On Fri, Jan 27, 2017 at 12:17 PM Christian Beikov <
christian.beikov(a)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.beikov(a)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(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev
12:50 p.m.
+1 to remove
On 27 January 2017 at 18:34, Vlad Mihalcea <mihalcea.vlad(a)gmail.com> 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 <steve(a)hibernate.org> wrote:
> Because the behavior is also fundamentally questionable.
>
> On Fri, Jan 27, 2017 at 12:17 PM Christian Beikov <
> christian.beikov(a)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.beikov(a)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(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>
_______________________________________________
hibernate-dev mailing list
hibernate-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev
1:16 p.m.
+1 for remove then too. We can still add it later via a configuration
property if someone complains.
Am 27.01.2017 um 19:50 schrieb Sanne Grinovero:
+1 to remove
On 27 January 2017 at 18:34, Vlad Mihalcea <mihalcea.vlad(a)gmail.com> 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 <steve(a)hibernate.org> wrote:
>
>> Because the behavior is also fundamentally questionable.
>>
>> On Fri, Jan 27, 2017 at 12:17 PM Christian Beikov <
>> christian.beikov(a)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.beikov(a)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(a)lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>>
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev
_______________________________________________
hibernate-dev mailing list
hibernate-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev
1:18 p.m.
They can always emulate it with a query that returns the ids and then just
call entityManager.find for each id so I don't think we'll ever need to add
it back.
Vlad
On Fri, Jan 27, 2017 at 9:16 PM, Christian Beikov <
christian.beikov(a)gmail.com> wrote:
+1 for remove then too. We can still add it later via a
configuration
property if someone complains.
Am 27.01.2017 um 19:50 schrieb Sanne Grinovero:
> +1 to remove
>
> On 27 January 2017 at 18:34, Vlad Mihalcea <mihalcea.vlad(a)gmail.com>
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 <steve(a)hibernate.org>
wrote:
>>
>>> Because the behavior is also fundamentally questionable.
>>>
>>> On Fri, Jan 27, 2017 at 12:17 PM Christian Beikov <
>>> christian.beikov(a)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.beikov(a)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(a)lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>>>
>> _______________________________________________
>> hibernate-dev mailing list
>> hibernate-dev(a)lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev
_______________________________________________
hibernate-dev mailing list
hibernate-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev
2:37 p.m.
+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 <mihalcea.vlad(a)gmail.com> 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 <steve(a)hibernate.org> wrote:
>
>> Because the behavior is also fundamentally questionable.
>>
>> On Fri, Jan 27, 2017 at 12:17 PM Christian Beikov <
>> christian.beikov(a)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.beikov(a)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(a)lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>>
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev
_______________________________________________
hibernate-dev mailing list
hibernate-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev
6:36 p.m.
+1 to remove
On 28 Jan 2017 20:44, "Chris Cranford" <chris(a)hibernate.org> 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 <mihalcea.vlad(a)gmail.com>
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 <steve(a)hibernate.org>
wrote:
>>
>>> Because the behavior is also fundamentally questionable.
>>>
>>> On Fri, Jan 27, 2017 at 12:17 PM Christian Beikov <
>>> christian.beikov(a)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.beikov(a)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(a)lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>>>
>> _______________________________________________
>> hibernate-dev mailing list
>> hibernate-dev(a)lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev
_______________________________________________
hibernate-dev mailing list
hibernate-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev
6:24 a.m.
https://hibernate.atlassian.net/browse/HHH-11443
On Sat, Jan 28, 2017 at 6:38 PM andrea boriero <andrea(a)hibernate.org> wrote:
+1 to remove
On 28 Jan 2017 20:44, "Chris Cranford" <chris(a)hibernate.org> 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 <mihalcea.vlad(a)gmail.com>
> 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
<steve(a)hibernate.org>
> wrote:
> >>
> >>> Because the behavior is also fundamentally questionable.
> >>>
> >>> On Fri, Jan 27, 2017 at 12:17 PM Christian Beikov <
> >>> christian.beikov(a)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.beikov(a)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(a)lists.jboss.org
> >>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
> >>>
> >> _______________________________________________
> >> hibernate-dev mailing list
> >> hibernate-dev(a)lists.jboss.org
> >> https://lists.jboss.org/mailman/listinfo/hibernate-dev
> > _______________________________________________
> > hibernate-dev mailing list
> > hibernate-dev(a)lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/hibernate-dev
>
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev(a)lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>
_______________________________________________
hibernate-dev mailing list
hibernate-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev
2637
days inactive
2643
days old
12 comments
6 participants
participants (6)
-
andrea boriero -
Chris Cranford -
Christian Beikov -
Sanne Grinovero -
Steve Ebersole -
Vlad Mihalcea