Hibernate Search 6.0.0.Alpha6 released
by Yoann Rodiere
Hello,
We just published Hibernate Search 6.0.0.Alpha6, a new release of the
still-in-development 6.0 branch.
This release mainly restores decent performance for Lucene index reads and
writes, adds support for indexing BigDecimal and BigInteger, reduces the
verbosity of the search DSL, and adds support for configuring on-commit
synchronization for automatic indexing.
As an Alpha, this version is an early technology preview. Be sure to read
about it on our blog before you try it out:
http://in.relation.to/2019/05/27/hibernate-search-6-0-0-Alpha6/
Cheers,
Yoann Rodière
Hibernate NoORM Team
yoann(a)hibernate.org
6 years
hibernate.jpa.compliance.caching and nullable secondary tables
by Gail Badner
The Javadoc for JpaCompliance#isJpaCacheComplianceEnabled says:
* @implNote Effects include marking all secondary tables as non-optional.
The reason
* being that optional secondary tables can lead to entity cache being
invalidated rather
* than updated.
But, the way it's used is the opposite (marks all secondary tables as
optional): [1]
isNullableTable[j] = join.isOptional()
|| creationContext.getSessionFactory()
.getSessionFactoryOptions()
.getJpaCompliance()
.isJpaCacheComplianceEnabled();
Even if a secondary table is explicitly mapped as non-optional using
@org.hibernate.annotations.Table(appliesTo=...,optional=false),
when hibernate.jpa.compliance.caching=true, Hibernate assumes that
secondary tables are nullable. This causes an outer join to be used in
queries, when an inner join could be used instead.
The property was added by HHH-12282 [2], which also mentions that the
intention is to mark all tables as non-optional. HHH-12282 also has a
comment [3] that says:
"I think its safe enough here to simply say that compliance means we omit
the table-span check at all."
Should the determination of whether a table is nullable depends only
on org.hibernate.mapping.Join#isOptional, like the following?
isNullableTable[j] = join.isOptional();
JpaCompliance().isJpaCacheComplianceEnabled() == true would still skip
invalidation.
WDYT?
Regards,
Gail
[1]
https://github.com/hibernate/hibernate-orm/blob/master/hibernate-core/src...
[2] https://hibernate.atlassian.net/browse/HHH-12282
[3]
https://hibernate.atlassian.net/browse/HHH-12282?focusedCommentId=101168&...
6 years
in.relation.to -- HTTPS
by Gunnar Morling
Hi all,
Just tried to reach in.relation.to via HTTPS, but it doesn't connect. Has
it not been moved to HTTPS yet, or is something broken there?
--Gunnar
6 years
NoORM IRC meeting minutes
by Guillaume Smet
Hi,
Here are the minutes of this week's meeting (no bot for me so copy/paste
FTW):
15:04 < gsmet> #startmeeting
15:04 < gsmet> not having the bot there really starts to be an issue
15:04 < fax4ever> :/
15:04 < gsmet> anyway, let's start
15:04 < gsmet> #topic Progress Davide
15:04 < ddalto> The most interesting thing that happened is that I went to
London and talk with Mark Paluch (Spring Data Project Lead
15:04 < ddalto> ) and showed him the Hibernate Rx API.
15:05 < ddalto> Mark pointed out a couple of things that are a bit
inconsistent and might be worth to have a look.
15:05 < ddalto> I also saw his presentation on r2dbc (Reactive Relational
Database Connectivity) where he focused on the differences between
async/reactive
15:06 < ddalto> Other than that I continue to work on the reactive API
15:06 < fax4ever> nice!
15:07 -!- chammer [~
chatzilla(a)p200300C4BF0C4E00E9728938CEEE8926.dip0.t-ipconnect.de] has joined
#hibernate-dev
15:07 < chammer> eclipse-dev
15:07 < ddalto> That's mostly my sprint
15:07 < gsmet> ok, thanks
15:08 < gsmet> #topic Next 2 weeks Davide
15:09 < ddalto> I'm going to spend some time studying the r2dbc project
15:09 < ddalto> and see if I can adapt the API to be more consistent
15:09 < ddalto> I also have a PR on OGM that I need to look
15:10 < ddalto> That's all
15:10 < gsmet> ok, thanks
15:10 < gsmet> #topic Progress Fabio
15:10 < fax4ever> We skiped the meeting last time.
15:10 < fax4ever> So the progess this time will be about the last 4 weeks
of activity.
15:10 < fax4ever> Firstly, we fixed some pending pull requests,
15:10 < fax4ever> such as the one to check the analyzer compatibility
15:11 < fax4ever> for multi-index-full-text fields.
15:11 < fax4ever> Secondly, we did the issue about ElasticSearch schema
validation.
15:11 < fax4ever> In our tests we cover now all supported attributes.
15:11 < fax4ever> In the process we removed some attributes, like boost and
fieldData,
15:11 < fax4ever> and we discovered that the default of 'doc_values' from
15:11 < fax4ever> Elasticsearch 5 is really 'true' as declared in
Elasticsearch doc.
15:11 < fax4ever> Thirdly, we applied the new the built-in normalize method
15:11 < fax4ever> provided by Lucene whenever we need a normalization.
15:12 < fax4ever> The trick here was to override some methods in
TokenizerChain class.
15:12 < fax4ever> It was necessary because we don't use the Lucene-provided
CustomAnalyzer builder.
15:12 < fax4ever> Fourtly, we made thread safe
LuceneDistanceToFieldProjection class.
15:12 < fax4ever> The query builder cannot change the instance anymore,
15:12 < fax4ever> it only can change its own context.
15:12 < fax4ever> Fifthly, we avoided for any case the use of the Hibernate
Search session,
15:12 < fax4ever> if the underlying Hibernate ORM session is closed.
15:13 < fax4ever> if the underlying Hibernate ORM session is closed.
15:13 < fax4ever> Sixthly, I reviewed several pull requests, most of them
were quite extensive.
15:13 < fax4ever> Finally, the last two weeks were most about supporting
15:13 < fax4ever> the new annotation @DecimalScale and BigDecimal and
BigInteger backend field type.
15:13 < fax4ever> The rest of the time I reviewed further PRs.
15:13 < fax4ever> That's alla about the progress thanks
15:14 < gsmet> #topic Next 2 weeks Fabio
15:14 < fax4ever> I'm finishing the big pull request to support BigInteger
BigDecimal and scaling factor in general
15:14 < fax4ever> I'm almost to finish
15:15 < fax4ever> after I'll follow the lineup for the new sprint
15:15 < fax4ever> as usual
15:15 < fax4ever> so you can see our progress on the sprint page of jira
15:15 < fax4ever> that's all from me thanks
15:15 < gsmet> thanks
15:15 < gsmet> #topic Progress Guillaume
15:16 < gsmet> not much progress from my side
15:16 < gsmet> I reviewed and included a couple of Validator PRs
15:16 < gsmet> we had quite a few reports lately
15:16 < gsmet> Marko is fixing most of the bugs
15:16 < gsmet> we also had a significant external contributions which is
nice
15:17 < gsmet> other than that, I'm bugging Yoann about various things,
while I'm working on a Hibernate Search quickstart for Quarkus
15:17 < gsmet> hopefully, it's for the best but I admit I'm whining a lot :)
15:17 < fax4ever> cool!
15:17 < yrodiere> :)
15:17 < gsmet> #topic Next 2 weeks Guillaume
15:18 < gsmet> so I want to finish the guide + quickstart for Quarkus' next
release
15:18 < gsmet> I also have to update to the latest snapshots - next alpha
15:19 < gsmet> I also would like to release a new 6.0.x and a new
6.1.0.alpha for HV
15:19 < gsmet> that's it for me
15:19 < gsmet> #topic Progress Koen
15:19 < koentsje> i have been improving the create project wizard for the
quarkus tools
15:20 < koentsje> also continue the work on the cheat sheet
15:20 < koentsje> and i have tried to get continuous integration working
without much success, so i will definitely have to talk to yrodiere for this
15:21 < yrodiere> sure
15:21 < koentsje> but i did manage to set up a reddeer integration test
plugin
15:21 < koentsje> additionally i have released hibernate tools 5.3.10
15:22 < koentsje> and i have integrated the new release in the eclipse
tooling
15:22 < koentsje> and finally i have been working on integrating quarkus
0.15.0 into the eclipse tools
15:22 < koentsje> this is almost done, but still one or two loose ends
15:23 -!- sfikes [~sfikes(a)c-69-246-28-50.hsd1.ms.comcast.net] has joined
#hibernate-dev
15:23 < koentsje> that’s it
15:23 < gsmet> #topic Next 2 weeks Koen
15:23 < koentsje> first thing is finish the 0.15.0 integration
15:24 < koentsje> i also want to create a quarkus configuration for
running/debugging quarkus applications in eclipse
15:24 < koentsje> and improve the quarkus extensions view
15:25 < koentsje> and then, as said, investigate/implement continuous
integration
15:25 < koentsje> plus elaborate the reddeer automatic integration tests
15:25 < koentsje> if any time left, i want to investigate gradle for the
hibernate tools build
15:25 < koentsje> that will be it
15:26 < gsmet> ok, thanks
15:26 < gsmet> #topic Progress Yoann
15:26 < yrodiere> It's been a month for me too, so bear with me...
15:26 < yrodiere> First I sent a PR to add new APIs to declare dependencies
in bridges
15:26 < yrodiere> It was quite complicated to write, and probably even
worse to review (sorry Fabio!), but there are tests and in the end it got
merged
15:26 < yrodiere> I also upgraded Search 6 to ES 6.7.1 and 7
15:27 < yrodiere> Not a lot of changes there, just a bit of work to get rid
of some warnings
15:27 < yrodiere> That, and Fabio's work, got into the Search 6.0.0.Alpha5
release
15:27 < yrodiere> which was supposed to go into Quarkus 0.15, and maybe it
did, but we'll do another release before the Hibernate Search extension is
really advertised in Quarkus 0.16
15:27 < yrodiere> Then I worked on allowing users to configure the
"synchronization strategy" for automatic indexing in the Hibernate Search
ORM mapper
15:27 -!- sfikes [~sfikes(a)c-69-246-28-50.hsd1.ms.comcast.net] has quit
[Client Quit]
15:27 < yrodiere> This strategy basically describes how much to wait for
the indexing upon transaction commits
15:28 < yrodiere> There are three built-in strategies: "queued" (~ do not
wait), "committed" (~ wait until changes are persisted to disk, but don't
wait for them to be searchable) and "searchable" (you get the
idea)
15:28 < yrodiere> And there's also a way to plug in a custom strategy.
15:28 < yrodiere> The past two weeks, I fixed a bunch of tickets that were
really just waiting to be closed and were already fixed.
15:28 < yrodiere> I also submitted a PR to restore orchestration in the
Lucene backend
15:28 < yrodiere> Previously it was trivial, just serializing everything,
but that was supposed to be temporary
15:28 < yrodiere> As a result of this works the Lucene ITs went down from 2
minutes to 30s, which is nice
15:29 < fax4ever> ;)
15:29 < yrodiere> I suspect there is room for improvement, but at least
it's better than it used to be
15:29 < yrodiere> Beside that, I did some work on the Search DSL (again),
to make sure backends can fully extend it, down to the type of query and of
SearchResult.
15:29 < yrodiere> That's mainly to lay the groundwork for the introduction
of major backend-specific features, such as aggregations, which will
require a whole part of the DSL and probably a specific result
type too.
15:29 -!- sfikes [~sfikes(a)c-69-246-28-50.hsd1.ms.comcast.net] has joined
#hibernate-dev
15:29 < yrodiere> For good measure I introduced APIs for explaining query
score computation, which are different in Lucene and Elasticsearch: it
worked fine.
15:30 < yrodiere> I also changed the index schema declaration API a little
bit to force users to declare multi-valued fields, because we'll probably
need that information in the future.
15:30 < yrodiere> Finally..
15:30 < yrodiere> Yesterday and today, I worked on making the Search DSL
even less verbose by making some method calls optional
15:30 < yrodiere> It looks like this now:
15:30 < yrodiere> return Search.getSearchSession(em).search(Book.class)
15:30 < yrodiere> .predicate(f ->
f.simpleQueryString().onFields("title").matching(pattern))
15:30 < yrodiere> .sort(f -> f.byField("title_sort"))
15:30 < yrodiere> .fetchHits();
15:30 < yrodiere> Well it's not merged yet, but close.
15:30 < yrodiere> Next two weeks!
15:30 < gsmet> #topic Next 2 weeks Yoann
15:31 < yrodiere> There's a big PRs still pending, so I expect to have to
do some work to do based on the reviews
15:31 < yrodiere> I will also have to release Search 6.0.0.Alpha6 for
Quarkus 0.16
15:31 < yrodiere> And ideally I'd like to release some of the maintenance
branches, too... but I've been postponing these for so long... who knows?
15:31 < yrodiere> After that, I will try to make Hibernate Search work in
the modulepath.
15:31 < yrodiere> I started to look into it, and it looks possible, but
there are a few problems with service loading that I suspect are related to
the aggregatedClassLoader in ORM. I still have to investigate.
15:32 < yrodiere> The problem is mainly that we already advertised this as
something that "just works", and I discovered some time ago that no, it
definitely did not
15:32 < yrodiere> so I'd like to fix that
15:32 < yrodiere> There are a few other tickets, but the main one will be
about restoring APIs for per-class works (purge, flush, ...) in the ORM
mapper. For now they are not exposed to end-users in Search 6,
they are just SPIs.
15:32 < yrodiere> That's all from me!
15:33 < gsmet> #topic Additional topics
15:33 < gsmet> I will be attending Mix-IT on Thursday-Friday so probably
not very active
15:34 < gsmet> RH is the main sponsor of the conference so we need people
there
15:34 < yrodiere> When is the Quarkus release again?
15:34 < gsmet> I won't be able to organize the hangout so Yoann, you're
hereby nominated chair :)
15:34 < gsmet> Wed 29th
15:34 < yrodiere> sure
15:35 < yrodiere> ok, so you'll be able to try out the Search release on
monday/tuesday
15:35 < fax4ever> :)
15:35 < yrodiere> well, have fun :)
15:35 < gsmet> well, we won't have people on the stand all day as there are
a lot of talks
15:35 < gsmet> so I'll be working as time permits
15:36 < gsmet> I really want to test this lazy thing before you release
15:36 < gsmet> anyone has anything to add?
15:36 < yrodiere> nope
15:36 < fax4ever> not from me thanks
15:36 < gsmet> OK, so let's close the meeting and have some fun
copy/pasting to an email...
15:37 < gsmet> #endmeeting
Cheers,
--
Guillaume
6 years
Post-connect queries for 6.1?
by Jordan Gigov
I thought it would be good to have an API that will call any registered
queries upon connecting to the database, and maybe ones before returning it
to the connection pool.
I'm thinking it should be called in the implementations of ConnectionProvider
and MultiTenantConnectionProvider.
The basic purpose would be so you can set certain parameters. For example
in setting the timezone in PostgreSQL:
SET SESSION TIME ZONE 'UTC';
Or in MySQL:
SET SESSION time_zone = 'Europe/Berlin';
This would of course require dialect handling, and access to some of the
configuration settings given to the SessionFactory.
There should also be a way for users to customize these with a
per-persistence-unit configuration of some sort. They might want to pass
other such runtime tweaks.
Someone may want to send something like this to their MySQL:
SET SESSION sql_mode = 'TRADITIONAL,ANSI';
I realize it's too late to think about this for 6.0, but it's something to
consider for later on.
6 years, 1 month
HHH-11147 - bytecode based "proxies"
by Steve Ebersole
Over the last 3 weeks or so, we have put a lot of work into HHH-11147 which
essentially allows bytecode enhancement to behave like the more traditional
proxy feature (create a reference based solely on the entity id).
We are wrapping up development of that improvement, enhancement, change,
whatever-you-want-to-call-it... One remaining question however is how to
make this change available in terms of releases. It seems to big of a deal
to simply drop in a new bug-fix release.
Should we consider a 5.5 release? Push it to 6? Thoughts?
6 years, 1 month
JDK 13 - Early Access build 20 is available
by Rory O'Donnell
Hi Sanne,
*OpenJDK builds *- JDK 13 - Early Access build 20 is available at
http://jdk.java.net/13/
* These early-access , open-source builds are provided under the
o GNU General Public License, version 2, with the Classpath
Exception <http://openjdk.java.net/legal/gplv2+ce.html>.
* Changes in this build
<http://hg.openjdk.java.net/jdk/jdk/log?rev=reverse%28%22jdk-13%2B19%22%3A...>
* Release notes [1]
*Significant changes since the last availability email*
* build 20
o Removal of T-Systems Deutsche Telekom Root CA 2 certificate
(JDK-8222137)
o Add new FileSystems.newFileSystem methods (JDK-8218875)
o Enhance auto vectorization for x86 (JDK-8222074)
o Remove CollectorPolicy and its subclasses (JDK-8198505)
o Drop support for pre JDK 1.4 SocketImpl implementations
(JDK-8216978)
* build 19
o add support for generating method handles from a variable symbol
(JDK-8222744)
o mark new VM option AllowRedefinitionToAddOrDeleteMethods as
deprecated (JDK-8222934)
* build 18
o Improve String::equals warmup characteristics (JDK-8215017)
o [Containers] Improve systemd slice memory limit support
(JDK-8217338)
Bug fixes for issues reported by Open Source Projects
* build 20
o assert(Compile::current()->live_nodes() <
Compile::current()->max_node_limit()) failed: Live Node limit
exceeded limit (JDK-8219520)
o C2: MemNode::can_see_stored_value() ignores casts which carry
control dependency (JDK-8219902)
o New fix of the deadlock in sun.security.ssl.SSLSocketImpl
(JDK-8219991)
JEP updates since last email
* JEP 350: Dynamic CDS Archives <http://openjdk.java.net/jeps/350>
istargeted for JDK 13.
* JEP 351: ZGC: Uncommit Unused Memory
<http://openjdk.java.net/jeps/351> istargeted for JDK 13
* JEP 353: Reimplement the Legacy Socket API
<http://openjdk.java.net/jeps/353> moved to Candidate
* JEP 354: Switch Expressions <http://openjdk.java.net/jeps/354> moved
to Candidate.
OpenJDK Committers’ Workshop, 1–2 August 2019 [2]
Rgds,Rory
[1] http://jdk.java.net/13/release-notes
[2] https://mail.openjdk.java.net/pipermail/announce/2019-April/000269.html
--
Rgds, Rory O'Donnell
Quality Engineering Manager
Oracle EMEA, Dublin, Ireland
6 years, 1 month
Jenkins upgrade
by Yoann Rodiere
Hello,
TL;DR: I just updated Jenkins and its plugins. If things stop working
correctly, please let me know.
Some details below, in case I'm not here when things start to break down...
I updated Jenkins and its plugins to the latest versions, hoping to fix the
problem we've been having lately where we would only ever get a single EC2
slave.
The result was an AWS EC2 plugin that started many, many EC2 slaves, but on
the Jenkins side mapped all slaves to the same URL, which resulted in
multiple builds running concurrently on the same EC2 instance, which
obviously resulted in many failures.
I rolled back the AWS EC2 plugin from 1.42 to 1.39 (like I had to do a few
weeks ago), and things to be back to normal. It even works better than
before I attempted the upgrade: the plugin correctly spawns multiple slaves
as required.
Frankly I don't understand what is going on, but it works again so I'll
stop touching it. I suppose I should take the time to investigate, attempt
to reproduce the problem and report it to the plugin maintainers. I
currently do not have a few days to spare for that, so it'll wait...
For the record, I also had to do the following during the upgrade:
- I had to update the AWS permissions for the EC2 plugin:
https://wiki.jenkins.io/display/JENKINS/Amazon+EC2+Plugin#AmazonEC2Plugin...
- I had to install a plugin to ensure running builds are no longer
allowed to do whatever they want (~root permissions):
https://jenkins.io/doc/book/system-administration/security/build-authoriz...
Cheers,
Yoann Rodière
Hibernate NoORM Team
yoann(a)hibernate.org
6 years, 1 month
