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