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 > > Let me know what you think. > > Vlad > > On Wed, May 16, 2018 at 3:55 PM, Steve Ebersole <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> >> 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- >>> 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> >>> 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> >>>> 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 >>>>> >>>>> Let me know if anyone has anything against implementing this feature. >>>>> >>>>> Vlad >>>>> _______________________________________________ >>>>> 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
