Re: [hibernate-dev] 6.0 - Session#createFilter
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@lists.jboss.org > https://lists.jboss.org/mailman/listinfo/hibernate-dev ___ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev
Re: [hibernate-dev] 6.0 - Query literal rendering
May I ask what happened to the idea of not rendering through the literals at all and just "inject" them into the result tuple? We could even go as far as allowing expressions on constant values to be evaluated in memory instead of sending that to the DB. Other than that, the settings seem ok, but how does that affect subqueries? The same way? Or are subqueries the exception? Regards, Christian Am 31.12.2016 um 15:25 schrieb Steve Ebersole: > Currently in 6.0 I have code in place to render query literals as > PreparedStatement parameters, but only outside the SELECT clause. Many DBs > require special handling for parameters defined in the SELECT clause > general requiring to wrap in cast functions calls. > > I think it may be beneficial to allow the user to control this via a > setting. Specifically a multi-valued (enum) value with the following > possibility set: > > 1. NEVER > 2. ALWAYS > 3. OUTSIDE_SELECT > > First, does anyone have an issue with this proposal? Secondly does anyone > see other concerns that should be take into account? > ___ > hibernate-dev mailing list > hibernate-dev@lists.jboss.org > https://lists.jboss.org/mailman/listinfo/hibernate-dev ___ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev
Re: [hibernate-dev] 6.0 - Query literal rendering
I only have so many hours in the day :) Let's get comparable behavior working first and then attack more complex (although we all agree probably worthwhile in this case) after. On Mon, Jan 2, 2017 at 1:37 AM Christian Beikov wrote: > May I ask what happened to the idea of not rendering through the > literals at all and just "inject" them into the result tuple? We could > even go as far as allowing expressions on constant values to be > evaluated in memory instead of sending that to the DB. > > Other than that, the settings seem ok, but how does that affect > subqueries? The same way? Or are subqueries the exception? > > Regards, > > Christian > > Am 31.12.2016 um 15:25 schrieb Steve Ebersole: > > Currently in 6.0 I have code in place to render query literals as > > PreparedStatement parameters, but only outside the SELECT clause. Many > DBs > > require special handling for parameters defined in the SELECT clause > > general requiring to wrap in cast functions calls. > > > > I think it may be beneficial to allow the user to control this via a > > setting. Specifically a multi-valued (enum) value with the following > > possibility set: > > > > 1. NEVER > > 2. ALWAYS > > 3. OUTSIDE_SELECT > > > > First, does anyone have an issue with this proposal? Secondly does > anyone > > see other concerns that should be take into account? > > ___ > > hibernate-dev mailing list > > hibernate-dev@lists.jboss.org > > https://lists.jboss.org/mailman/listinfo/hibernate-dev > > ___ > hibernate-dev mailing list > hibernate-dev@lists.jboss.org > https://lists.jboss.org/mailman/listinfo/hibernate-dev > ___ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev
Re: [hibernate-dev] 6.0 - Session#createFilter
Field-access would have zero bearing on this On Mon, Jan 2, 2017 at 1:30 AM Christian Beikov 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@lists.jboss.org > > https://lists.jboss.org/mailman/listinfo/hibernate-dev > > ___ > hibernate-dev mailing list > hibernate-dev@lists.jboss.org > https://lists.jboss.org/mailman/listinfo/hibernate-dev > ___ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev
