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 ManagedBeanRegistry
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
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
FunctionContribut
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 variety of builder setti
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 som
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 wh
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
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
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 6.x.
>
> However, it's jus
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
t
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 passing custom SQL function
12 matches
Mail list logo