The functions could be contributed via a CDI/Spring bean which might not be such a bad idea I think. In a test environment there could be a different contributor active than in production. Of course, this could also be handled by passing in different configuration property values, but that's why I was saying I'm not sure about it. Maybe someone else has an idea if using ManagedBeanRegistry might make sense?
Mit freundlichen Grüßen, ------------------------------------------------------------------------ *Christian Beikov* Am 17.05.2018 um 16:49 schrieb Vlad Mihalcea: > Hi, > > Looking at the SessionFactoryImpl class, the only way to provide an > SqlFunction is either via the Dialect or via the SessionFactoryOptions: > this.sqlFunctionRegistry =new SQLFunctionRegistry( > jdbcServices.getJdbcEnvironment().getDialect(), > options.getCustomSqlFunctionMap() ); > I'm not sure if the ManagedBeanRegistry would have helped in this case > without requiring more code changes. > > Vlad > > On Thu, May 17, 2018 at 5:22 PM, Christian Beikov > <christian.bei...@gmail.com <mailto:christian.bei...@gmail.com>> wrote: > > It looks ok to me although I'm not sure if it wouldn't be more > appropriate to instantiate the contributor via ManagedBeanRegistry. > > > Mit freundlichen Grüßen, > ------------------------------------------------------------------------ > *Christian Beikov* > Am 17.05.2018 um 11:20 schrieb Vlad Mihalcea: > > In the end, I thought of a more generic approach to for JPA > bootstrapping > > which, not only allows us to register SqlFunctions, but we can > apply other > > changes on the MetadataBuilder object used during bootstrap. > > > > This is the Pull Request: > > > > https://github.com/hibernate/hibernate-orm/pull/2288 > <https://github.com/hibernate/hibernate-orm/pull/2288> > > > > Let me know what you think. > > > > Vlad > > > > On Wed, May 16, 2018 at 3:55 PM, Steve Ebersole > <st...@hibernate.org <mailto:st...@hibernate.org>> wrote: > > > >> Its not so much hindering 6.0 that I am concerned with. The > problem is > >> updatability for the user. The more things they use that > change = the more > >> work to upgrade. > >> > >> On Wed, May 16, 2018 at 6:51 AM Vlad Mihalcea > <mihalcea.v...@gmail.com <mailto:mihalcea.v...@gmail.com>> > >> wrote: > >> > >>> I suppose this will be refactored considerably in 6.x. > >>> > >>> However, it's just a small change and I don't think it will > hinder any > >>> 6.x changes. > >>> > >>> I'm thinking of defining an SqlFunctionContributor interface > >>> (@FunctionalInterface) > >>> which can be provided via the properties Map that's supplied > when using > >>> the Persistence#createEntityManagerFactory method. > >>> > >>> In EntityManagerFactoryBuilder, I can just inspect that and > pass it > >>> further to MetamodelBuilder. > >>> > >>> So, it does not take any effort to implement it and users can > benefit > >>> from it. I recently answered a question on the forum on this > topic: > >>> > >>> https://discourse.hibernate.org/t/i-cant-use-group-concat- > <https://discourse.hibernate.org/t/i-cant-use-group-concat-> > >>> in-queries/752/14 > >>> > >>> And, realized that I was wrong about suggesting doing it via the > >>> Integrator mechanism (since the Metamodel is already frozen by > the time we > >>> execute the Integrator). > >>> > >>> Vlad > >>> > >>> On Wed, May 16, 2018 at 2:41 PM, Steve Ebersole > <st...@hibernate.org <mailto:st...@hibernate.org>> > >>> wrote: > >>> > >>>> This should maybe wait for 6.0. We are ditching SQLFunction > in favor of > >>>> a more AST-friendly contract. > >>>> > >>>> Beyond that, go for it. > >>>> > >>>> > >>>> On Wed, May 16, 2018, 6:34 AM Vlad Mihalcea > <mihalcea.v...@gmail.com <mailto:mihalcea.v...@gmail.com>> > >>>> wrote: > >>>> > >>>>> Hi, > >>>>> > >>>>> I realized that only the native Hibernate bootstrapping > mechanism allows > >>>>> for passing custom SQL functions. > >>>>> > >>>>> For JPA, we can extend the Dialect to register, but that's > not always > >>>>> desirable as it requires a code change > >>>>> every time the user switches to a new Dialect version. > >>>>> > >>>>> For this reason, I created this Jira issue: > >>>>> > >>>>> https://hibernate.atlassian.net/browse/HHH-12589 > <https://hibernate.atlassian.net/browse/HHH-12589> > >>>>> > >>>>> Let me know if anyone has anything against implementing this > feature. > >>>>> > >>>>> Vlad > >>>>> _______________________________________________ > >>>>> hibernate-dev mailing list > >>>>> hibernate-dev@lists.jboss.org > <mailto:hibernate-dev@lists.jboss.org> > >>>>> https://lists.jboss.org/mailman/listinfo/hibernate-dev > <https://lists.jboss.org/mailman/listinfo/hibernate-dev> > >>>>> > > _______________________________________________ > > hibernate-dev mailing list > > hibernate-dev@lists.jboss.org <mailto:hibernate-dev@lists.jboss.org> > > https://lists.jboss.org/mailman/listinfo/hibernate-dev > <https://lists.jboss.org/mailman/listinfo/hibernate-dev> > > _______________________________________________ > hibernate-dev mailing list > hibernate-dev@lists.jboss.org <mailto:hibernate-dev@lists.jboss.org> > https://lists.jboss.org/mailman/listinfo/hibernate-dev > <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
