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 <[email protected]> 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 <[email protected]> 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 < >> [email protected]> wrote: >> >> As far as I understand from the documentation( >> https://docs.jboss.org/hibernate/orm/3.3/reference/en/html/objectstate.html#objectstate-filtering), >> 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/Session.html#createFilter >> >> 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 < >> [email protected]> 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 <[email protected]> >> 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 < >> [email protected]> 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 >> > [email protected] >> > https://lists.jboss.org/mailman/listinfo/hibernate-dev >> >> _______________________________________________ >> hibernate-dev mailing list >> [email protected] >> https://lists.jboss.org/mailman/listinfo/hibernate-dev >> >> >> >> >> > _______________________________________________ > hibernate-dev mailing list > [email protected] > https://lists.jboss.org/mailman/listinfo/hibernate-dev _______________________________________________ hibernate-dev mailing list [email protected] https://lists.jboss.org/mailman/listinfo/hibernate-dev
