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

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&gt; 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

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&gt; 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&gt; 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

> I plan on removing Session#createFilter. There are numerous reasons why which I can discuss if anyone is interested in exploring this. I'm curious, what are the reasons for removing it? And if we remove it, what's the alternative for people to use? 2016-12-31 21:00 GMT+01:00 Steve Ebersole <steve(a)hibernate.org&gt;: 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

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&gt; 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&gt; 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&gt; 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

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&gt; 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&gt; 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&gt; 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&gt; > 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&gt; 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

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&gt; 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&gt; 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&gt; 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&gt; 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&gt; >> 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&gt; 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

On Tue, Jan 3, 2017 at 5:31 AM Gunnar Morling <gunnar(a)hibernate.org&gt; wrote: > 2017-01-02 15:27 GMT+01:00 Steve Ebersole <steve(a)hibernate.org&gt;: > I realize now that Session#createFilter() is only geared towards > collections. So are you suggesting to only remove that method, but keep > @Filter/@FilterDef? > Correct. @Filter and @FilterDef are in NO WAY related to Session#createFilter

The plan with Stream support here is exactly that... translate the map, filter etc calls into a SQL query.

On Tue, Jan 3, 2017 at 4:41 AM Sanne Grinovero <sanne(a)hibernate.org&gt; wrote: > > 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&gt; 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&gt; > > 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&gt; 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&gt; 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&gt; > >> 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&gt; 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

+1 On 01/03/2017 10:02 AM, andrea boriero wrote: > +1 for removing createFilter() > > On 3 January 2017 at 15:54, Gunnar Morling <gunnar(a)hibernate.org&gt; wrote: > >> 2017-01-03 15:28 GMT+01:00 Steve Ebersole <steve(a)hibernate.org&gt;: >> >>> On Tue, Jan 3, 2017 at 5:31 AM Gunnar Morling <gunnar(a)hibernate.org&gt; >>> wrote: >>> >>>> 2017-01-02 15:27 GMT+01:00 Steve Ebersole <steve(a)hibernate.org&gt;: >>>> I realize now that Session#createFilter() is only geared towards >>>> collections. So are you suggesting to only remove that method, but keep >>>> @Filter/@FilterDef? >>>> >>> >>> Correct. @Filter and @FilterDef are in NO WAY related to >>> Session#createFilter >>> >> Ok. then +1 from my side for removing createFilter() . >> _______________________________________________ >> 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