https://hibernate.atlassian.net/browse/HHH-11443
On Sat, Jan 28, 2017 at 6:38 PM andrea boriero wrote:
> +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 Janu
+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.
> >>
> >> V
+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 t
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.bei...@gmail.com> wrote:
> +1 for remove then too. We can still add i
+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 wrote:
>> I'm for removing it even if it didn't complicate the query parser.
>>
>> Vl
+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:1
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,
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 o
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:
On Fri, Jan 27, 2017 at 9:51 AM Christian Beikov
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 mee
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 f
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 t
12 matches
Mail list logo
