[hibernate-dev] Simplify SQL function registration when bootstrapping via JPA

[Christian Beikov]

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.beikov at gmail.com <mailto:christian.beikov at 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
>     <steve at hibernate.org <mailto:steve at 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.vlad at gmail.com <mailto:mihalcea.vlad at 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
>     <steve at hibernate.org <mailto:steve at 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.vlad at gmail.com <mailto:mihalcea.vlad at 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 at lists.jboss.org
>     <mailto:hibernate-dev at 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 at lists.jboss.org <mailto:hibernate-dev at 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 at lists.jboss.org <mailto:hibernate-dev at lists.jboss.org>
>     https://lists.jboss.org/mailman/listinfo/hibernate-dev
>     <https://lists.jboss.org/mailman/listinfo/hibernate-dev>
>
>