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
