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 <christian.bei...@gmail.com> 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
