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,
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
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
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 cust
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
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 pre
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:
>
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 functions could be contributed via a CDI/Spring bean which might not
be such a bad idea I think. In a test environment there could be a
different contributor active than in production. Of course, this could
also be handled by passing in different configuration property values,
but that's wh
I personally agree with Christian, I don't see the use of the
ManagedBeanRegistry being a problem. The new interface certainly opens
the door for a variety of builder settings to be contributed easily and
using the registry allows for a versatile way to provide that bean,
whether it be through som
Sure thing. I'll try to adapt it to using the Bean registry.
Vlad
On Thu, 17 May 2018, 20:07 Chris Cranford, wrote:
> I personally agree with Christian, I don't see the use of the
> ManagedBeanRegistry being a problem. The new interface certainly opens
> the door for a variety of builder setti
I 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.
Personally I think both a contributor and CDI integration
(ManagedBeanRegitry) make sense here. Btw, the name for the contributor
should not be SqlFunctionContributor - it should reflect the ultimate goal
here which is SqmFunctionTemplate; I can see SqmFunctionContributor or just
FunctionContribut
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 th
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 instr
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
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
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 su
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?
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
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
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
22 matches
Mail list logo
