7:07 p.m.
I personally agree with Christian, I don't see the use of the
ManagedBeanRegistry being a problem. The new interface certainly opens
the door for a variety of builder settings to be contributed easily and
using the registry allows for a versatile way to provide that bean,
whether it be through some CDI/Spring environment or the fallback
solution where we instantiate it ourselves. I believe the code as you
have it can easily be adapted to use the registry by replacing the
"newInstance()" call with a call into getting the bean from the
registry. The registry itself internally should handle getting the bean
from the container or returning you a new instance we instantiate ourselves.
On 05/17/2018 12:25 PM, Christian Beikov wrote:
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(a)gmail.com <mailto:christian.beikov@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(a)hibernate.org <mailto:steve@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(a)gmail.com <mailto:mihalcea.vlad@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(a)hibernate.org <mailto:steve@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(a)gmail.com <mailto:mihalcea.vlad@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(a)lists.jboss.org
> <mailto:hibernate-dev@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(a)lists.jboss.org <mailto:hibernate-dev@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(a)lists.jboss.org <mailto:hibernate-dev@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(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev