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

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

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

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

Re: [hibernate-dev] Stride

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

Re: [hibernate-dev] Stride

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

Re: [hibernate-dev] Stride

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

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

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

Re: [hibernate-dev] Stride

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

Re: [hibernate-dev] Stride

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

Re: [hibernate-dev] Stride

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

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

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

[hibernate-dev] Stride

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.

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

Sure thing. I'll try to adapt it to using the Bean registry. Vlad On Thu, 17 May 2018, 20:07 Chris Cranford, wrote: > I personally agree with Christian, I don't see the use of the > ManagedBeanRegistry being a problem. The new interface certainly opens > the door for a

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

I personally agree with Christian, I don't see the use of the ManagedBeanRegistry being a problem.  The new interface certainly opens the door for a variety of builder settings to be contributed easily and using the registry allows for a versatile way to provide that bean, whether it be through

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

The functions could be contributed via a CDI/Spring bean which might not be such a bad idea I think. In a test environment there could be a different contributor active than in production. Of course, this could also be handled by passing in different configuration property values, but that's

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

Hi, Looking at the SessionFactoryImpl class, the only way to provide an SqlFunction is either via the Dialect or via the SessionFactoryOptions: this.sqlFunctionRegistry = new SQLFunctionRegistry( jdbcServices.getJdbcEnvironment().getDialect(), options.getCustomSqlFunctionMap() ); I'm not sure

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

It looks ok to me although I'm not sure if it wouldn't be more appropriate to instantiate the contributor via ManagedBeanRegistry. Mit freundlichen Grüßen, *Christian Beikov* Am 17.05.2018 um 11:20 schrieb Vlad Mihalcea: >

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

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

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

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

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

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

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

In the end, I thought of a more generic approach to for JPA bootstrapping which, not only allows us to register SqlFunctions, but we can apply other changes on the MetadataBuilder object used during bootstrap. This is the Pull Request: https://github.com/hibernate/hibernate-orm/pull/2288 Let me

[hibernate-dev] Hibernate Search 5.10.0.Final released

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