[hibernate-dev] 6.0 - Session#createFilter

Sanne Grinovero sanne at hibernate.org
Tue Jan 3 05:41:25 EST 2017


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 at 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 at 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 at gmail.com> 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 <
>> christian.beikov at 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 at 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 at 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 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
>>
>>
>>
>>
>>
> _______________________________________________
> 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