[hibernate-dev] Hibernate Search 5.10.0.Final released

[Yoann Rodiere]

Hello,

We just published Hibernate Search 5.10.0.Final, the first stable release
in the 5.10 branch. This release mainly brings an upgrade to Hibernate ORM
5.3 and JPA 2.2, but also an integration to dependency injection frameworks
through Hibernate ORM 5.3, an upgrade to WildFly 12 and JGroups 4, and Java
9 automatic module names.

Check out our blog for more information about this release:

http://in.relation.to/2018/05/17/hibernate-search-5-10-0-Final/
-- 
Yoann Rodiere
yo...@hibernate.org / yrodi...@redhat.com
Software Engineer
Hibernate NoORM team
___
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] Cache region names are not prefixed in 5.3

[Sanne Grinovero]

I think this is the RegionFactory's responsibility, as Hibernate ORM
alone can't know if this is necessary.

Prefixing is one of many options to isolate caches; a Cache technology
might wish to use a different approach by implementing a custom
`org.hibernate.cache.spi.CacheKeysFactory`.

Not least the server / deployer might be able to hint the Cache
provider to tell if isolation is at all necessary.

In conclusion, by having Hibernate ORM not messing with prefixes
allows other technologies to implement more efficient solutions. Our
own code also ends up being more efficient by not needing to add a
prefix during each and every access to the cache.

Thanks,
Sanne

On 17 May 2018 at 06:34, Gail Badner  wrote:
> I see that cache region names are not being prefixed in 5.3.
>
> EnabledCaching sets the TimestampsRegion region name
> to TimestampsRegion.class.getName(), and sets the QueryResultsRegion region
> name to QueryResultsRegion.class.getName(). [1]
>
> Without a prefix, WildFly is failing intermittently when there are 2
> persistence units with the query cache enabled due to:
>
> org.infinispan.commons.CacheConfigurationException: ISPN000453: Attempt to
> define configuration for cache org.hibernate.cache.spi.TimestampsRegion
> which already exists
>
> Entity region names are not being prefixed either.
>
> Should they be prefixed by Hibernate or by the RegionFactory?
>
> Regards,
> Gail
>
> [1]
> https://github.com/hibernate/hibernate-orm/blob/master/hibernate-core/src/main/java/org/hibernate/cache/internal/EnabledCaching.java#L80-L92
> ___
> 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] Cache region names are not prefixed in 5.3

[Sanne Grinovero]

On 17 May 2018 at 11:11, Sanne Grinovero  wrote:
> I think this is the RegionFactory's responsibility, as Hibernate ORM
> alone can't know if this is necessary.
>
> Prefixing is one of many options to isolate caches; a Cache technology
> might wish to use a different approach by implementing a custom
> `org.hibernate.cache.spi.CacheKeysFactory`.

Hum, I regret how I wrote the above paragraph.

I actually meant that a Cache technology could implement isolation in
many different ways.
Using a custom `CacheKeysFactory` is just an example, there are many
other options as well. In fact, I believe a good choice for
application servers would be to have an independent CacheManager for
each deployment. Then it can safely inspect the deployment, see if
there are multiple Persistence Units using the same caching
technology, and implement further isolation only if necessary.

These thoughts are a consequence of a chat I had with Paul Ferraro
from the WildFly team, as he mentioned the size of the keys becoming
problematic with all the additional prefixing they need to apply. I
hope this will make it possible to e.g. create an "as small as
possible" unique identifier for the deployments to replace the
deployment name during serialization (to identify the CacheManager)
followed by a numeric id indexing the PUs within the deployment - or
nothing altogether in case of single PUs.

Of course, I don't expect that to be needed right away; the
RegionFactory could just do good old prefixing for now but I hope
we'll explore such improvements in the near future.

Thanks,
Sanne

>
> Not least the server / deployer might be able to hint the Cache
> provider to tell if isolation is at all necessary.
>
> In conclusion, by having Hibernate ORM not messing with prefixes
> allows other technologies to implement more efficient solutions. Our
> own code also ends up being more efficient by not needing to add a
> prefix during each and every access to the cache.
>
> Thanks,
> Sanne
>
> On 17 May 2018 at 06:34, Gail Badner  wrote:
>> I see that cache region names are not being prefixed in 5.3.
>>
>> EnabledCaching sets the TimestampsRegion region name
>> to TimestampsRegion.class.getName(), and sets the QueryResultsRegion region
>> name to QueryResultsRegion.class.getName(). [1]
>>
>> Without a prefix, WildFly is failing intermittently when there are 2
>> persistence units with the query cache enabled due to:
>>
>> org.infinispan.commons.CacheConfigurationException: ISPN000453: Attempt to
>> define configuration for cache org.hibernate.cache.spi.TimestampsRegion
>> which already exists
>>
>> Entity region names are not being prefixed either.
>>
>> Should they be prefixed by Hibernate or by the RegionFactory?
>>
>> Regards,
>> Gail
>>
>> [1]
>> https://github.com/hibernate/hibernate-orm/blob/master/hibernate-core/src/main/java/org/hibernate/cache/internal/EnabledCaching.java#L80-L92
>> ___
>> 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] Cache region names are not prefixed in 5.3

[Radim Vansa]

I basically agree with Sanne here that having the prefix isolated opens 
space for performance improvements, though if certain call is prefixed, 
RegionFactory can always drop that prefix. The important thing is to 
mention if the region name is prefixed or not in javadocs. I would also 
prefer if *all* region names that RegionFactory is supposed to access 
followed the same strategy (prefixed/not-prefixed).

5.1 included method

     QueryResultsRegion buildQueryResultsRegion(String regionName, 
Properties properties)

where StandardQueryCache did the prefix for us, the change in 5.3 to

     QueryResultsRegion buildQueryResultsRegion(String regionName, 
SessionFactoryImplementor sessionFactory)

does not indicate that the prefix won't be there and the javadoc is 
missing completely.

Also, DomainDataRegionConfig.getRegionName() has no javadoc and 
RegionFactory does not add the prefix.

@Steve could you please amend the javadoc and confirm if RF should 
prefix region names?

@Sanne while cache manager per deployment is an obvious way to 
distinguish regions@deployments, CM holds some heavy resources (e.g. 
threads) - so I while we are supposed to scale number of caches up to 
thousands (and we've fixed some problems that arise when you have for 
example ~3k caches), ATM you're not supposed to scale CMs. And I don't 
think that we'll focus in this direction since the bright future lies in 
microservices :)

Radim

On 05/17/2018 12:23 PM, Sanne Grinovero wrote:
> On 17 May 2018 at 11:11, Sanne Grinovero  wrote:
>> I think this is the RegionFactory's responsibility, as Hibernate ORM
>> alone can't know if this is necessary.
>>
>> Prefixing is one of many options to isolate caches; a Cache technology
>> might wish to use a different approach by implementing a custom
>> `org.hibernate.cache.spi.CacheKeysFactory`.
> Hum, I regret how I wrote the above paragraph.
>
> I actually meant that a Cache technology could implement isolation in
> many different ways.
> Using a custom `CacheKeysFactory` is just an example, there are many
> other options as well. In fact, I believe a good choice for
> application servers would be to have an independent CacheManager for
> each deployment. Then it can safely inspect the deployment, see if
> there are multiple Persistence Units using the same caching
> technology, and implement further isolation only if necessary.
>
> These thoughts are a consequence of a chat I had with Paul Ferraro
> from the WildFly team, as he mentioned the size of the keys becoming
> problematic with all the additional prefixing they need to apply. I
> hope this will make it possible to e.g. create an "as small as
> possible" unique identifier for the deployments to replace the
> deployment name during serialization (to identify the CacheManager)
> followed by a numeric id indexing the PUs within the deployment - or
> nothing altogether in case of single PUs.
>
> Of course, I don't expect that to be needed right away; the
> RegionFactory could just do good old prefixing for now but I hope
> we'll explore such improvements in the near future.
>
> Thanks,
> Sanne
>
>> Not least the server / deployer might be able to hint the Cache
>> provider to tell if isolation is at all necessary.
>>
>> In conclusion, by having Hibernate ORM not messing with prefixes
>> allows other technologies to implement more efficient solutions. Our
>> own code also ends up being more efficient by not needing to add a
>> prefix during each and every access to the cache.
>>
>> Thanks,
>> Sanne
>>
>> On 17 May 2018 at 06:34, Gail Badner  wrote:
>>> I see that cache region names are not being prefixed in 5.3.
>>>
>>> EnabledCaching sets the TimestampsRegion region name
>>> to TimestampsRegion.class.getName(), and sets the QueryResultsRegion region
>>> name to QueryResultsRegion.class.getName(). [1]
>>>
>>> Without a prefix, WildFly is failing intermittently when there are 2
>>> persistence units with the query cache enabled due to:
>>>
>>> org.infinispan.commons.CacheConfigurationException: ISPN000453: Attempt to
>>> define configuration for cache org.hibernate.cache.spi.TimestampsRegion
>>> which already exists
>>>
>>> Entity region names are not being prefixed either.
>>>
>>> Should they be prefixed by Hibernate or by the RegionFactory?
>>>
>>> Regards,
>>> Gail
>>>
>>> [1]
>>> https://github.com/hibernate/hibernate-orm/blob/master/hibernate-core/src/main/java/org/hibernate/cache/internal/EnabledCaching.java#L80-L92
>>> ___
>>> hibernate-dev mailing list
>>> hibernate-dev@lists.jboss.org
>>> https://lists.jboss.org/mailman/listinfo/hibernate-dev


-- 
Radim Vansa 
JBoss Performance Team

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

Re: [hibernate-dev] Cache region names are not prefixed in 5.3

[Sanne Grinovero]

On 17 May 2018 at 12:09, Radim Vansa  wrote:
> I basically agree with Sanne here that having the prefix isolated opens
> space for performance improvements, though if certain call is prefixed,
> RegionFactory can always drop that prefix. The important thing is to mention
> if the region name is prefixed or not in javadocs. I would also prefer if
> *all* region names that RegionFactory is supposed to access followed the
> same strategy (prefixed/not-prefixed).
>
> 5.1 included method
>
> QueryResultsRegion buildQueryResultsRegion(String regionName, Properties
> properties)
>
> where StandardQueryCache did the prefix for us, the change in 5.3 to
>
> QueryResultsRegion buildQueryResultsRegion(String regionName,
> SessionFactoryImplementor sessionFactory)
>
> does not indicate that the prefix won't be there and the javadoc is missing
> completely.
>
> Also, DomainDataRegionConfig.getRegionName() has no javadoc and
> RegionFactory does not add the prefix.
>
> @Steve could you please amend the javadoc and confirm if RF should prefix
> region names?
>
> @Sanne while cache manager per deployment is an obvious way to distinguish
> regions@deployments, CM holds some heavy resources (e.g. threads) - so I
> while we are supposed to scale number of caches up to thousands (and we've
> fixed some problems that arise when you have for example ~3k caches), ATM
> you're not supposed to scale CMs. And I don't think that we'll focus in this
> direction since the bright future lies in microservices :)

Right, good points. It's a possible optimization I'd like to see
eventually but it's not trivial to get there yet.

Yet assuming a microservices scenario, this does become trivial to
benefit from: the container knows there's a single deployment, a
single CM. So no need to isolate them at all, just need to possibly
isolate multiple PUs defined in the same service.

So it will be easy to run hundreds of isolated microservices on the
same physical CPU and kill each other via process contention :P

>
> Radim
>
>
> On 05/17/2018 12:23 PM, Sanne Grinovero wrote:
>>
>> On 17 May 2018 at 11:11, Sanne Grinovero  wrote:
>>>
>>> I think this is the RegionFactory's responsibility, as Hibernate ORM
>>> alone can't know if this is necessary.
>>>
>>> Prefixing is one of many options to isolate caches; a Cache technology
>>> might wish to use a different approach by implementing a custom
>>> `org.hibernate.cache.spi.CacheKeysFactory`.
>>
>> Hum, I regret how I wrote the above paragraph.
>>
>> I actually meant that a Cache technology could implement isolation in
>> many different ways.
>> Using a custom `CacheKeysFactory` is just an example, there are many
>> other options as well. In fact, I believe a good choice for
>> application servers would be to have an independent CacheManager for
>> each deployment. Then it can safely inspect the deployment, see if
>> there are multiple Persistence Units using the same caching
>> technology, and implement further isolation only if necessary.
>>
>> These thoughts are a consequence of a chat I had with Paul Ferraro
>> from the WildFly team, as he mentioned the size of the keys becoming
>> problematic with all the additional prefixing they need to apply. I
>> hope this will make it possible to e.g. create an "as small as
>> possible" unique identifier for the deployments to replace the
>> deployment name during serialization (to identify the CacheManager)
>> followed by a numeric id indexing the PUs within the deployment - or
>> nothing altogether in case of single PUs.
>>
>> Of course, I don't expect that to be needed right away; the
>> RegionFactory could just do good old prefixing for now but I hope
>> we'll explore such improvements in the near future.
>>
>> Thanks,
>> Sanne
>>
>>> Not least the server / deployer might be able to hint the Cache
>>> provider to tell if isolation is at all necessary.
>>>
>>> In conclusion, by having Hibernate ORM not messing with prefixes
>>> allows other technologies to implement more efficient solutions. Our
>>> own code also ends up being more efficient by not needing to add a
>>> prefix during each and every access to the cache.
>>>
>>> Thanks,
>>> Sanne
>>>
>>> On 17 May 2018 at 06:34, Gail Badner  wrote:

 I see that cache region names are not being prefixed in 5.3.

 EnabledCaching sets the TimestampsRegion region name
 to TimestampsRegion.class.getName(), and sets the QueryResultsRegion
 region
 name to QueryResultsRegion.class.getName(). [1]

 Without a prefix, WildFly is failing intermittently when there are 2
 persistence units with the query cache enabled due to:

 org.infinispan.commons.CacheConfigurationException: ISPN000453: Attempt
 to
 define configuration for cache org.hibernate.cache.spi.TimestampsRegion
 which already exists

 Entity region names are not being prefixed either.

 Should they be prefixed by Hibernate or by the RegionFactory?

 Regards,
 Gail

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]

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]

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

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 
>> mailto: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
>> mailto:st...@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
>> mailto:mihalcea.v...@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
>> mailto:st...@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
>> mailto:mihalcea.v...@gmail.com>>
>>  wrote:
>> 
>> > Hi,
>> >
>> > I realized that only the native Hibernate bootstrapping
>> mechanism allows
>> > for passing c

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
> >> mailto: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
> >> mailto:st...@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
> >> mailto:mihalcea.v...@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
> >> mailto:st...@hibernate.org>>
> >> >>> wrote:
> >> >>>
> >>  This should maybe wait for 6.0.  We are ditching SQLFunction
> >> in favor of
> >>  a more AST-friendly contract.
> >> 
> 

[hibernate-dev] Stride

[Steve Ebersole]

I got an email from Atlassian this morning about the migration from HipChat
to Stride.  Basically they have not gotten Stride feature-complete in terms
of HipChat which is the trigger for the mass migration.  However, they are
reaching out to all waiting teams to see if any want to migrate anyway.
The list of missing features they sent me are:


   1. Guest access
   2. Some admin controls and compliance settings
   3. Integrations with Atlassian server products (the Jira Server app is
   currently in beta and coming soon) and some other popular integrations. See
   all available Stride integrations
   

   .
   4. User management via API
   5. Dark mode

I am not really sure exactly what is missing WRT (2).  (3) is nice-to-have,
but not blocker IMO assuming it gets added at some point.

I think (1) is the only one that is concerning.  Though TBH for myself
personally, I do not think registering is a big deal.

Unless I hear otherwise, I plan on asking them to proceed with our
migration to Stride.
___
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]

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
> > >> mailto: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
> > >> mailto:st...@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
> > >> mailto:mihalcea.v...@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-
> > >> 

Re: [hibernate-dev] Stride

[Guillaume Smet]

Hi Steve,

Hum. I see at least 1/ and 3/ as being annoying. I personally like to have
the JIRA/GitHub/Jenkins notifications on HipChat.

What would be the advantages of migrating so soon?

On Thu, May 17, 2018 at 8:03 PM, Steve Ebersole  wrote:

> I got an email from Atlassian this morning about the migration from HipChat
> to Stride.  Basically they have not gotten Stride feature-complete in terms
> of HipChat which is the trigger for the mass migration.  However, they are
> reaching out to all waiting teams to see if any want to migrate anyway.
> The list of missing features they sent me are:
>
>
>1. Guest access
>2. Some admin controls and compliance settings
>3. Integrations with Atlassian server products (the Jira Server app is
>currently in beta and coming soon) and some other popular integrations.
> See
>all available Stride integrations
> 454855738b8db6340974f28f3c2e1e6aa7c674a6314ad5df11014e5e2ee3
> 9bd3d4326606d2826b241a>
>.
>4. User management via API
>5. Dark mode
>
> I am not really sure exactly what is missing WRT (2).  (3) is nice-to-have,
> but not blocker IMO assuming it gets added at some point.
>
> I think (1) is the only one that is concerning.  Though TBH for myself
> personally, I do not think registering is a big deal.
>
> Unless I hear otherwise, I plan on asking them to proceed with our
> migration to Stride.
> ___
> 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] Stride

[Sanne Grinovero]

lol, I was writing about the same to the team list.

+1 to have people register, it's better for them anyway. I checked
it's easier to self-register.

+1 to migrate quickly. It's clear we don't want to stay on HipChat, if
this doesn't work out we'll see.

Refer to my parallel email for Fedora instructions.

Thanks,
Sanne


On 17 May 2018 at 19:03, Steve Ebersole  wrote:
> I got an email from Atlassian this morning about the migration from HipChat
> to Stride.  Basically they have not gotten Stride feature-complete in terms
> of HipChat which is the trigger for the mass migration.  However, they are
> reaching out to all waiting teams to see if any want to migrate anyway.
> The list of missing features they sent me are:
>
>
>1. Guest access
>2. Some admin controls and compliance settings
>3. Integrations with Atlassian server products (the Jira Server app is
>currently in beta and coming soon) and some other popular integrations. See
>all available Stride integrations
>
> 
>.
>4. User management via API
>5. Dark mode
>
> I am not really sure exactly what is missing WRT (2).  (3) is nice-to-have,
> but not blocker IMO assuming it gets added at some point.
>
> I think (1) is the only one that is concerning.  Though TBH for myself
> personally, I do not think registering is a big deal.
>
> Unless I hear otherwise, I plan on asking them to proceed with our
> migration to Stride.
> ___
> 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] Stride

[Sanne Grinovero]

On 17 May 2018 at 19:11, Guillaume Smet  wrote:
> Hi Steve,
>
> Hum. I see at least 1/ and 3/ as being annoying. I personally like to have
> the JIRA/GitHub/Jenkins notifications on HipChat.

JIRA and GitHub integrations are available already.

I'm confident Jenkins won't take long:
 - https://jira.atlassian.com/browse/STRIDE-1973

> What would be the advantages of migrating so soon?

We'll know sooner if we like it :)
___
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 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
>> > >> mailto: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
>> > >> 
>> > >> >
>> > >> > L

Re: [hibernate-dev] Stride

[Guillaume Smet]

Well, can we at least wait for the Jenkins integration then?

If as you say "it won't take long", we won't have long to wait.

Frankly, I don't see why we would want to rush into this migration...
especially since Stride is not ready yet. We will be part of the first
users to migrate and I'm not sure it's a good idea.

We also need someone with the time to configure correctly all the
integrations.

If we don't have all the features we use now (not talking about the ones we
don't use), I'm pretty sure it won't be better.

A chat system that works is essential to our work.

On Thu, May 17, 2018 at 8:20 PM, Sanne Grinovero 
wrote:

> On 17 May 2018 at 19:11, Guillaume Smet  wrote:
> > Hi Steve,
> >
> > Hum. I see at least 1/ and 3/ as being annoying. I personally like to
> have
> > the JIRA/GitHub/Jenkins notifications on HipChat.
>
> JIRA and GitHub integrations are available already.
>
> I'm confident Jenkins won't take long:
>  - https://jira.atlassian.com/browse/STRIDE-1973
>
> > What would be the advantages of migrating so soon?
>
> We'll know sooner if we like it :)
>
___
hibernate-dev mailing list
hibernate-dev@lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev

Re: [hibernate-dev] Stride

[Guillaume Smet]

By the way, you say it’s clear we don’t want to stay on HipChat. 

When did we decide that? I don’t remember a discussion about it. 

For sure, we probably won’t have a choice because there’s a good chance 
Atlassian will close the service but what are the problems that make a 
migration so urgent?

> Le 17 mai 2018 à 20:16, Sanne Grinovero  a écrit :
> 
> lol, I was writing about the same to the team list.
> 
> +1 to have people register, it's better for them anyway. I checked
> it's easier to self-register.
> 
> +1 to migrate quickly. It's clear we don't want to stay on HipChat, if
> this doesn't work out we'll see.
> 
> Refer to my parallel email for Fedora instructions.
> 
> Thanks,
> Sanne
> 
> 
>> On 17 May 2018 at 19:03, Steve Ebersole  wrote:
>> I got an email from Atlassian this morning about the migration from HipChat
>> to Stride.  Basically they have not gotten Stride feature-complete in terms
>> of HipChat which is the trigger for the mass migration.  However, they are
>> reaching out to all waiting teams to see if any want to migrate anyway.
>> The list of missing features they sent me are:
>> 
>> 
>>   1. Guest access
>>   2. Some admin controls and compliance settings
>>   3. Integrations with Atlassian server products (the Jira Server app is
>>   currently in beta and coming soon) and some other popular integrations. See
>>   all available Stride integrations
>>   
>> 
>>   .
>>   4. User management via API
>>   5. Dark mode
>> 
>> I am not really sure exactly what is missing WRT (2).  (3) is nice-to-have,
>> but not blocker IMO assuming it gets added at some point.
>> 
>> I think (1) is the only one that is concerning.  Though TBH for myself
>> personally, I do not think registering is a big deal.
>> 
>> Unless I hear otherwise, I plan on asking them to proceed with our
>> migration to Stride.
>> ___
>> 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] Stride

[Sanne Grinovero]

On 17 May 2018 at 20:32, Guillaume Smet  wrote:
> By the way, you say it’s clear we don’t want to stay on HipChat.
>
> When did we decide that? I don’t remember a discussion about it.

I didn't say it was decided, but I think we're working on that since
Steve asked about it today. To which I agree *because* it seems clear
to me that we don't want to stay on it - a notion I inferred from
multiple previous discussions.

Steve pointed out multiple flaws e.g. the native client packaging
broken on Fedora, to which Atlassian pretty much replied by letting us
know they won't invest in HipChat as the future is Stride. We can
choose when to switch but staying doesn't look sensible to me as it
certainly won't improve; it's also likely that they'll want everyone
migrated eventually so to shut the existing service down.

I for one gave up as well installing the native client and have been
using the web client since setting up my new workstation, as I was
expecting Stride to arrive soon.

The other day some people tried to join and gave up because of login
complexity - that's IMO a very bad sign: not welcoming community
people means it's failing its primary requirements.

And let's not forget all authentication nonsense; especially days that
I'm working more on the WildFly side of things and need to login to
multiple instances I really look forward to a better system (hopefully
it is!?).

Question, since you want a decision: are you only suggesting to delay
or suggesting that you should rather stay on HipChat?

Personally, I'm fine delaying a bit even though I can live happily
without Jenkins notifications, but let's hear the others as well.

Thanks,
Sanne


>
> For sure, we probably won’t have a choice because there’s a good chance 
> Atlassian will close the service but what are the problems that make a 
> migration so urgent?
>
>> Le 17 mai 2018 à 20:16, Sanne Grinovero  a écrit :
>>
>> lol, I was writing about the same to the team list.
>>
>> +1 to have people register, it's better for them anyway. I checked
>> it's easier to self-register.
>>
>> +1 to migrate quickly. It's clear we don't want to stay on HipChat, if
>> this doesn't work out we'll see.
>>
>> Refer to my parallel email for Fedora instructions.
>>
>> Thanks,
>> Sanne
>>
>>
>>> On 17 May 2018 at 19:03, Steve Ebersole  wrote:
>>> I got an email from Atlassian this morning about the migration from HipChat
>>> to Stride.  Basically they have not gotten Stride feature-complete in terms
>>> of HipChat which is the trigger for the mass migration.  However, they are
>>> reaching out to all waiting teams to see if any want to migrate anyway.
>>> The list of missing features they sent me are:
>>>
>>>
>>>   1. Guest access
>>>   2. Some admin controls and compliance settings
>>>   3. Integrations with Atlassian server products (the Jira Server app is
>>>   currently in beta and coming soon) and some other popular integrations. 
>>> See
>>>   all available Stride integrations
>>>   
>>> 
>>>   .
>>>   4. User management via API
>>>   5. Dark mode
>>>
>>> I am not really sure exactly what is missing WRT (2).  (3) is nice-to-have,
>>> but not blocker IMO assuming it gets added at some point.
>>>
>>> I think (1) is the only one that is concerning.  Though TBH for myself
>>> personally, I do not think registering is a big deal.
>>>
>>> Unless I hear otherwise, I plan on asking them to proceed with our
>>> migration to Stride.
>>> ___
>>> 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] Cache region names are not prefixed in 5.3

[Gail Badner]

I see that HHH-11356 removed prefixes from region names used by Hibernate.

I also noticed that entity regions are unprefixed and the package name is
removed.

I've created 2 issues:
HHH-12599 to add Javadoc to make it clear that region names are unprefixed;
HHH-12598 to add the package onto entity region names.

Should I create an ISPN issue for hibernate-infinispan (or whatever it's
referred to now) to add the prefixes?

On Thu, May 17, 2018 at 4:55 AM, Sanne Grinovero 
wrote:

> On 17 May 2018 at 12:09, Radim Vansa  wrote:
> > I basically agree with Sanne here that having the prefix isolated opens
> > space for performance improvements, though if certain call is prefixed,
> > RegionFactory can always drop that prefix. The important thing is to
> mention
> > if the region name is prefixed or not in javadocs. I would also prefer if
> > *all* region names that RegionFactory is supposed to access followed the
> > same strategy (prefixed/not-prefixed).
> >
> > 5.1 included method
> >
> > QueryResultsRegion buildQueryResultsRegion(String regionName,
> Properties
> > properties)
> >
> > where StandardQueryCache did the prefix for us, the change in 5.3 to
> >
> > QueryResultsRegion buildQueryResultsRegion(String regionName,
> > SessionFactoryImplementor sessionFactory)
> >
> > does not indicate that the prefix won't be there and the javadoc is
> missing
> > completely.
> >
> > Also, DomainDataRegionConfig.getRegionName() has no javadoc and
> > RegionFactory does not add the prefix.
> >
> > @Steve could you please amend the javadoc and confirm if RF should prefix
> > region names?
> >
> > @Sanne while cache manager per deployment is an obvious way to
> distinguish
> > regions@deployments, CM holds some heavy resources (e.g. threads) - so I
> > while we are supposed to scale number of caches up to thousands (and
> we've
> > fixed some problems that arise when you have for example ~3k caches), ATM
> > you're not supposed to scale CMs. And I don't think that we'll focus in
> this
> > direction since the bright future lies in microservices :)
>
> Right, good points. It's a possible optimization I'd like to see
> eventually but it's not trivial to get there yet.
>
> Yet assuming a microservices scenario, this does become trivial to
> benefit from: the container knows there's a single deployment, a
> single CM. So no need to isolate them at all, just need to possibly
> isolate multiple PUs defined in the same service.
>
> So it will be easy to run hundreds of isolated microservices on the
> same physical CPU and kill each other via process contention :P
>
> >
> > Radim
> >
> >
> > On 05/17/2018 12:23 PM, Sanne Grinovero wrote:
> >>
> >> On 17 May 2018 at 11:11, Sanne Grinovero  wrote:
> >>>
> >>> I think this is the RegionFactory's responsibility, as Hibernate ORM
> >>> alone can't know if this is necessary.
> >>>
> >>> Prefixing is one of many options to isolate caches; a Cache technology
> >>> might wish to use a different approach by implementing a custom
> >>> `org.hibernate.cache.spi.CacheKeysFactory`.
> >>
> >> Hum, I regret how I wrote the above paragraph.
> >>
> >> I actually meant that a Cache technology could implement isolation in
> >> many different ways.
> >> Using a custom `CacheKeysFactory` is just an example, there are many
> >> other options as well. In fact, I believe a good choice for
> >> application servers would be to have an independent CacheManager for
> >> each deployment. Then it can safely inspect the deployment, see if
> >> there are multiple Persistence Units using the same caching
> >> technology, and implement further isolation only if necessary.
> >>
> >> These thoughts are a consequence of a chat I had with Paul Ferraro
> >> from the WildFly team, as he mentioned the size of the keys becoming
> >> problematic with all the additional prefixing they need to apply. I
> >> hope this will make it possible to e.g. create an "as small as
> >> possible" unique identifier for the deployments to replace the
> >> deployment name during serialization (to identify the CacheManager)
> >> followed by a numeric id indexing the PUs within the deployment - or
> >> nothing altogether in case of single PUs.
> >>
> >> Of course, I don't expect that to be needed right away; the
> >> RegionFactory could just do good old prefixing for now but I hope
> >> we'll explore such improvements in the near future.
> >>
> >> Thanks,
> >> Sanne
> >>
> >>> Not least the server / deployer might be able to hint the Cache
> >>> provider to tell if isolation is at all necessary.
> >>>
> >>> In conclusion, by having Hibernate ORM not messing with prefixes
> >>> allows other technologies to implement more efficient solutions. Our
> >>> own code also ends up being more efficient by not needing to add a
> >>> prefix during each and every access to the cache.
> >>>
> >>> Thanks,
> >>> Sanne
> >>>
> >>> On 17 May 2018 at 06:34, Gail Badner  wrote:
> 
>  I see that cache region names are not being prefixed in 5.3.
>

Re: [hibernate-dev] Cache region names are not prefixed in 5.3

[Gail Badner]

On Thu, May 17, 2018 at 5:24 PM, Gail Badner  wrote:

> I see that HHH-11356 removed prefixes from region names used by Hibernate.
>
> I also noticed that entity regions are unprefixed and the package name is
> removed.
>

Actually, the package names are being included in the region names. The
test I was looking at did not have a package.


>
> I've created 2 issues:
> HHH-12599 to add Javadoc to make it clear that region names are unprefixed;
> HHH-12598 to add the package onto entity region names.
>

I've rejected HHH-12598.


>
> Should I create an ISPN issue for hibernate-infinispan (or whatever it's
> referred to now) to add the prefixes?
>
> On Thu, May 17, 2018 at 4:55 AM, Sanne Grinovero 
> wrote:
>
>> On 17 May 2018 at 12:09, Radim Vansa  wrote:
>> > I basically agree with Sanne here that having the prefix isolated opens
>> > space for performance improvements, though if certain call is prefixed,
>> > RegionFactory can always drop that prefix. The important thing is to
>> mention
>> > if the region name is prefixed or not in javadocs. I would also prefer
>> if
>> > *all* region names that RegionFactory is supposed to access followed the
>> > same strategy (prefixed/not-prefixed).
>> >
>> > 5.1 included method
>> >
>> > QueryResultsRegion buildQueryResultsRegion(String regionName,
>> Properties
>> > properties)
>> >
>> > where StandardQueryCache did the prefix for us, the change in 5.3 to
>> >
>> > QueryResultsRegion buildQueryResultsRegion(String regionName,
>> > SessionFactoryImplementor sessionFactory)
>> >
>> > does not indicate that the prefix won't be there and the javadoc is
>> missing
>> > completely.
>> >
>> > Also, DomainDataRegionConfig.getRegionName() has no javadoc and
>> > RegionFactory does not add the prefix.
>> >
>> > @Steve could you please amend the javadoc and confirm if RF should
>> prefix
>> > region names?
>> >
>> > @Sanne while cache manager per deployment is an obvious way to
>> distinguish
>> > regions@deployments, CM holds some heavy resources (e.g. threads) - so
>> I
>> > while we are supposed to scale number of caches up to thousands (and
>> we've
>> > fixed some problems that arise when you have for example ~3k caches),
>> ATM
>> > you're not supposed to scale CMs. And I don't think that we'll focus in
>> this
>> > direction since the bright future lies in microservices :)
>>
>> Right, good points. It's a possible optimization I'd like to see
>> eventually but it's not trivial to get there yet.
>>
>> Yet assuming a microservices scenario, this does become trivial to
>> benefit from: the container knows there's a single deployment, a
>> single CM. So no need to isolate them at all, just need to possibly
>> isolate multiple PUs defined in the same service.
>>
>> So it will be easy to run hundreds of isolated microservices on the
>> same physical CPU and kill each other via process contention :P
>>
>> >
>> > Radim
>> >
>> >
>> > On 05/17/2018 12:23 PM, Sanne Grinovero wrote:
>> >>
>> >> On 17 May 2018 at 11:11, Sanne Grinovero  wrote:
>> >>>
>> >>> I think this is the RegionFactory's responsibility, as Hibernate ORM
>> >>> alone can't know if this is necessary.
>> >>>
>> >>> Prefixing is one of many options to isolate caches; a Cache technology
>> >>> might wish to use a different approach by implementing a custom
>> >>> `org.hibernate.cache.spi.CacheKeysFactory`.
>> >>
>> >> Hum, I regret how I wrote the above paragraph.
>> >>
>> >> I actually meant that a Cache technology could implement isolation in
>> >> many different ways.
>> >> Using a custom `CacheKeysFactory` is just an example, there are many
>> >> other options as well. In fact, I believe a good choice for
>> >> application servers would be to have an independent CacheManager for
>> >> each deployment. Then it can safely inspect the deployment, see if
>> >> there are multiple Persistence Units using the same caching
>> >> technology, and implement further isolation only if necessary.
>> >>
>> >> These thoughts are a consequence of a chat I had with Paul Ferraro
>> >> from the WildFly team, as he mentioned the size of the keys becoming
>> >> problematic with all the additional prefixing they need to apply. I
>> >> hope this will make it possible to e.g. create an "as small as
>> >> possible" unique identifier for the deployments to replace the
>> >> deployment name during serialization (to identify the CacheManager)
>> >> followed by a numeric id indexing the PUs within the deployment - or
>> >> nothing altogether in case of single PUs.
>> >>
>> >> Of course, I don't expect that to be needed right away; the
>> >> RegionFactory could just do good old prefixing for now but I hope
>> >> we'll explore such improvements in the near future.
>> >>
>> >> Thanks,
>> >> Sanne
>> >>
>> >>> Not least the server / deployer might be able to hint the Cache
>> >>> provider to tell if isolation is at all necessary.
>> >>>
>> >>> In conclusion, by having Hibernate ORM not messing with prefixes
>> >>> allows other technolo