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

There could conceivably be multiple MetadataBuilderContributor instances needing to be integrated. CDI (and therefore ManagedBeanRegistry) do not work well in this situation. MetadataBuilderContributor should be done via ServiceLoader (via ClassLoaderService) When I mentioned

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

I named it MetadataBuilderContributor because you can do more than just registering SqlFunctions. While implementing it, I realized that, this way, it's going to be very flexible to customize the Hibernate-native Metadata while doing the JPA bootstrap. Related to ManagedBeanRegitry, I'm trying to

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

Personally I think both a contributor and CDI integration (ManagedBeanRegitry) make sense here. Btw, the name for the contributor should not be SqlFunctionContributor - it should reflect the ultimate goal here which is SqmFunctionTemplate; I can see SqmFunctionContributor or just

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

Sure thing. I'll try to adapt it to using the Bean registry. Vlad On Thu, 17 May 2018, 20:07 Chris Cranford, wrote: > 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

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

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

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

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

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

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

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

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: >

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

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

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

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 wrote: > I suppose this will be refactored considerably in

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

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

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

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 wrote: > Hi, > > I realized that only the native Hibernate bootstrapping mechanism allows > for