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

[Steve Ebersole]

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 was talking specifically about just
contributing functions - but MetadataBuilderContributor is more
generalized, which is fine.. it just won't fit into the CDI paradigm




On Thu, May 17, 2018 at 1:35 PM Vlad Mihalcea 
wrote:

> 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 convert to using it, but
> stumbled on this issue.
>
> If I try to get a Bean like this:
>
> managedBeanRegistry.getBean( MetadataBuilderContributor.class );
>
> And there is no BeanContainer set via
> "hibernate.resource.beans.container", then the FallbackContainedBean is
> used, which tries to instantiate the provided interface:
>
> beanType.newInstance();
>
> But since I provide an interface, the call will fail.
>
> The only workaround I found is this:
>
> ManagedBeanRegistry managedBeanRegistry = standardServiceRegistry
> .getService( ManagedBeanRegistry.class );
>
> BeanContainer beanContainer = managedBeanRegistry.getBeanContainer();
>
> ManagedBean
> metadataBuilderContributorManagedBean = null;
> if ( beanContainer != null ) {
> metadataBuilderContributorManagedBean = managedBeanRegistry
> .getBean( MetadataBuilderContributor.class );
> }
>
> MetadataBuilderContributor metadataBuilderContributor =
> metadataBuilderContributorManagedBean
> .getBeanInstance();
>
> Am I using it the wrong way, or do we need to check the BeanContainer
> first to make sure it's not null before getting a Bean from the
> ManagedBeanRegistry?
>
> Vlad
>
>
> On Thu, May 17, 2018 at 9:07 PM, Steve Ebersole 
> wrote:
>
>> 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
>> FunctionContributor.  This is an example of what I meant about waiting for
>> 6...
>>
>> On Thu, May 17, 2018 at 12:50 PM Vlad Mihalcea 
>> wrote:
>>
>>> 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 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
>>> > >> >
>>> wrote:
>>> > >>
>>> > >> It looks ok to me although I'm not sure if it wouldn't be more
>>> > >> 

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

[Vlad Mihalcea]

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 convert to using it, but
stumbled on this issue.

If I try to get a Bean like this:

managedBeanRegistry.getBean( MetadataBuilderContributor.class );

And there is no BeanContainer set via "hibernate.resource.beans.container",
then the FallbackContainedBean is used, which tries to instantiate the
provided interface:

beanType.newInstance();

But since I provide an interface, the call will fail.

The only workaround I found is this:

ManagedBeanRegistry managedBeanRegistry = standardServiceRegistry
.getService( ManagedBeanRegistry.class );

BeanContainer beanContainer = managedBeanRegistry.getBeanContainer();

ManagedBean
metadataBuilderContributorManagedBean = null;
if ( beanContainer != null ) {
metadataBuilderContributorManagedBean = managedBeanRegistry
.getBean( MetadataBuilderContributor.class );
}

MetadataBuilderContributor metadataBuilderContributor =
metadataBuilderContributorManagedBean
.getBeanInstance();

Am I using it the wrong way, or do we need to check the BeanContainer first
to make sure it's not null before getting a Bean from the
ManagedBeanRegistry?

Vlad


On Thu, May 17, 2018 at 9:07 PM, Steve Ebersole  wrote:

> 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
> FunctionContributor.  This is an example of what I meant about waiting for
> 6...
>
> On Thu, May 17, 2018 at 12:50 PM Vlad Mihalcea 
> wrote:
>
>> 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 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
>> > >> >
>> 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

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

[Steve Ebersole]

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
FunctionContributor.  This is an example of what I meant about waiting for
6...

On Thu, May 17, 2018 at 12:50 PM Vlad Mihalcea 
wrote:

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

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

[Vlad Mihalcea]

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 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
> >> > 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
> >> > 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
> >> >
> >> >> 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
> >> >
> >> >>> wrote:
> >> >>>
> >>  This should maybe wait 

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

[Chris Cranford]

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 
>> > 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
>> > 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
>> >
>> >> 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
>> >
>> >>> 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
>> >
>>  wrote:
>> 
>> > Hi,
>> 

Re: [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 
> > 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
> > 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
> >
> >> 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
> >
> >>> 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
> >
>  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@lists.jboss.org
> 

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

[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.bei...@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 
> 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 
> >> 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 
> >>> 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 
>  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@lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/hibernate-dev
> >
> > ___
> > hibernate-dev mailing list
> > hibernate-dev@lists.jboss.org
> > https://lists.jboss.org/mailman/listinfo/hibernate-dev
>
> ___
> hibernate-dev mailing list
> hibernate-dev@lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>
___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev

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

[Christian Beikov]

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  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 
>> 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 
>>> 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 
 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@lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>
> ___
> hibernate-dev mailing list
> hibernate-dev@lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev

___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev

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

[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  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 
> 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 
>> 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 
>>> 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@lists.jboss.org
 https://lists.jboss.org/mailman/listinfo/hibernate-dev

>>>
>>
___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev

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

[Steve Ebersole]

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 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 
> 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 
>> 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@lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>>>
>>
>
___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev

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

[Vlad Mihalcea]

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  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 
> 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@lists.jboss.org
>> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>>
>
___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev

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

[Steve Ebersole]

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 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@lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>
___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev

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

[Vlad Mihalcea]

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@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev