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

Vlad Mihalcea mihalcea.vlad at gmail.com
Thu May 17 10:49:21 EDT 2018


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> 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
> >
> > Let me know what you think.
> >
> > Vlad
> >
> > On Wed, May 16, 2018 at 3:55 PM, Steve Ebersole <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>
> >> 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 <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>
> >>>> 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 at lists.jboss.org
> >>>>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
> >>>>>
> > _______________________________________________
> > hibernate-dev mailing list
> > hibernate-dev at lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/hibernate-dev
>
> _______________________________________________
> hibernate-dev mailing list
> hibernate-dev at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>


More information about the hibernate-dev mailing list