I wonder if "use streams" is a reasonable replacement for all power
users who might have needed this? We know by experience there's loads
of such people not reading this list, so maybe we'd need a deprecation
cycle.
I don't mean to dive deeply in implementation details and plans, but I
suspect that the createFilter approach was able to limit the amount of
data we pump out of the database into the Java heap, while a solution
based on Java8 streams would post-filter the data, unless you plan to
have Hibernate able to convert all filter predicates into SQL? (which
sounds awesome but I wasn't expecting that soon..)
Just wondering if that might be unacceptable to people mapping very
large collections.
Thanks,
Sanne
On 2 January 2017 at 15:41, Steve Ebersole <steve(a)hibernate.org> wrote:
Christian and I chatted on HipChat. It seems his confusion stems
partially
from misunderstanding #createFilter, but also the fact that I did not go
into detail regarding the plans for this streaming support. I thought it
would be a good idea to discuss that at a high level here. The main thing
to bear in mind is that intention is such that there stream calls would be
translated into SQL rather than resolved in memory (aka get a huge
ResultSet and filter etc based on the stream calls).
This email was just meant to discuss the removal of the #createFilter
method so I did not go into detail. Also too, the design of that is still
a discussion point. Initially I am thinking it would leverage the JPA
metamodel, e.g. the static metamodel (the generated Order_ stuff).
I should also point out that I completely plan to remove #createFilter in
6.0 and not introduce this streaming stuff until 6.x. 6.0 is already
getting beyond its initial scope and I's much rather get 6.0 released
earlier and "oftener" :)
On Mon, Jan 2, 2017 at 9:11 AM Steve Ebersole <steve(a)hibernate.org> wrote:
> Well stop and think about it... What do you expect session.filter( new
> ArrayList(), "<some HQL>") to do?
>
> Yes, it has to be a PersistentCollection. Hibernate handles "persistent
> arrays" as well
> (see org.hibernate.collection.internal.PersistentArrayHolder), although it
> is a discouraged feature.
>
> It is used to apply:
>
> 1. an implicit from-clause element for the collection owner (named
> "this")
> 2. a restriction on the PersistentCollection's owner.
>
> So a filter like I mentioned before (`session.createFilter(
> customer.getOrders(), "orderDate < currentDate() - {3 months}" )`) is
> really the same as (it is literally converted to this internally):
>
> `select elements( this.orders ) from Customer this where this.id =
> <this-customer-id> and orderDate < currentDate() - {3 months}`
>
>
> On Mon, Jan 2, 2017 at 8:45 AM Christian Beikov <
> christian.beikov(a)gmail.com> wrote:
>
> As far as I understand from the documentation(
>
https://docs.jboss.org/hibernate/orm/3.3/reference/en/html/objectstate.ht...),
> it can be used to filter collections and arrays. I don't know if it only
> works for persistent collections but since arrays are also mentioned, I
> guess not.
> I'd expect the collection or array to be filtered and projected in-memory
> if possible, thus not executing a query unless needed for a lazy collection
> or additional from clause.
>
> If that understanding is wrong, please help me understand what the purpose
> is then.
>
>
> Am 02.01.2017 um 12:37 schrieb Steve Ebersole:
>
> I think you are not understanding createFilter:
>
>
>
http://docs.jboss.org/hibernate/orm/current/javadocs/org/hibernate/Sessio...
>
> Again, to call filter you'd have to have access to the Collection you want
> to filter.
>
> On Mon, Jan 2, 2017 at 2:40 AM Christian Beikov <
> christian.beikov(a)gmail.com> wrote:
>
> Let's say we have this entity with an attribute that is not directly
> exposed.
>
> class EntityA { String field; }
>
> and then you pass a collection of EntityA instances to createFilter like
>
> Collection<EntityA> collection = ...
> collection = session.createFilter(collection, "field =
> 'abc%'").getResultList();
>
> See my point? Since Hibernate can access the field directly, this works,
> but with streams you'd need to expose the field via a getter so you can
> filter for it.
>
>
> Am 02.01.2017 um 09:25 schrieb Steve Ebersole:
>
> Could you explain the situation where you would map a collection but not
> expose it? And btw even create createFilter would not work there because
> you have to pass createFilter the collection
>
> On Mon, Jan 2, 2017, 2:15 AM Christian Beikov <christian.beikov(a)gmail.com>
> wrote:
>
> Well it does when you consider that there might be no getter for a field.
> With createFilter you could still filter the result list without exposing
> direct access to the field via a getter.
>
> Am 02.01.2017 um 08:52 schrieb Steve Ebersole:
>
> Field-access would have zero bearing on this
>
> On Mon, Jan 2, 2017 at 1:30 AM Christian Beikov <
> christian.beikov(a)gmail.com> wrote:
>
> Sounds good to me, but maybe we could do a poll to see if people are
> using this? I don't know if the filter also works for field based access
> strategy, but that could be a reason for keeping it around.
>
> Regards,
>
> Christian
>
>
> Am 31.12.2016 um 21:00 schrieb Steve Ebersole:
> > As I have not been hearing hardly any feedback on these 6.0 design
> > questions I have been trying to start, I'll be doing something different
> in
> > this and any additional emails.. I'll state what I propose to do and if
> > anyone has issue with it they can make a counter proposal. Otherwise I
> > plan on following through with my proposal.
> >
> > I plan on removing Session#createFilter. There are numerous reasons why
> > which I can discuss if anyone is interested in exploring this.
> >
> > Ultimately I think it makes sense to handle this via Java 8 streams[1]
> > although I am not sure that needs to happen in 6.0
> >
> > [1]
https://hibernate.atlassian.net/browse/HHH-10962
> > _______________________________________________
> > 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