[hibernate-dev] Query#iterate

Vlad Mihalcea mihalcea.vlad at gmail.com
Fri Jan 27 12:39:01 EST 2017


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 at 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 at lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/hibernate-dev
>
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>


More information about the hibernate-dev mailing list