Github now offers an option to not create the "merge commit" when you
want to merge a PR from the web ui.
It comes at a significant cost though: it will merge the PR but squash
all commits in one.
While initially thinking that doesn't help us at all, at second
thought: we really want any non-trivial code change to be checked out
locally, run the testsuite, and only then push.
But let's say there's a trivial PR fixing some typos in documentation!
You look at it, looks good and then you really just want to say "go
ahead" and get back to more important matters. Besides, we have
Jenkins carefully testing these too and it will grey out the button if
the build fails, so there's some kind of last defence in case you
didn't notice that the "docs typo" PR actually sneaks in some real
So I'd say we could enable this option with the "squashing" ?
We would still refrain from using the green button for most patches,
but it could save some "boring process" minutes for those simpler
I've enabled this option for Hibernate Search. We can seek team
consensus before actually using it (you're not supposed to use the
"green button" at all currently), I might at least have it default to
the less annoying option: if you do use it by mistake, it will squash
The open question remains if we're ok to use it regularly for trivial
PRs, and if you want this switched on all Hibernate repositories.
Gunnar suggested that I find a first task for you to familiarize with
the project, and to have you practice the process of creating patches
and proposing them for integration over GitHub.
I think this issue could be suited:
I hope it's not too boring! It's not just an exercise, we need that
done so it would be a valuable contribution already.
Do you have an account on our JIRA server? If not create one, then let
me know your user id so I can assign the issue to you.
I was hoping that even w/o a specific OGM sprint we would soon (next
week?) be able to re-spin the CR1 with minor effort as the
Among tasks scheduled for 5.0.0.Final:
I'm assigned two documentation related issues; these seem important
enough to stay flagged for 5.0.0.Final and should be doable. OGM-888
also relates documentation and should be doable.
Could we agree on moving out the other open issues?
Personally I think the only one needing some attention still is:
- OGM-817 Adapt to changes around auto-quoting
While reviewing the PR for this issue:
I realized that the ReadWrite cache concurrency strategy has a flaw that
permits "read uncommitted" anomalies.
The RW cache concurrency strategy guards any modifications with Lock
entries, as explained in this post that I wrote some time ago:
Every time we update/delete an entry, a Lock is put in the cache under the
entity key, and, this way, "read uncommitted" anomalies should be prevented.
The problem comes when entries are evicted either explicitly:
session.refresh( item1 );
During eviction, the 2PL will remove the Lock entry, and if the user
attempts to load the entity anew (in the same transaction that has modified
the entity but which is not committed yet), an uncommitted change could be
propagated to the 2PL.
This issue is replicated by the PR associated to this Jira issue, and I
also replicated it with manual eviction and entity loading.
To fix it, the RW cache concurrency strategy should not delete entries from
2PL upon eviction, but instead it should turn them in Lock entries.
For the evict method, this is not really a problem, but evictAll would
imply taking all entries and replacing them with Locks, and that might not
perform very well in a distributed-cache scenario.
Ideally, lock entries would be stored separately than actual cached value
entries, and this problem would be fixed in a much cleaner fashion.
Let me know what you think about this.
The Apache Lucene team is voting on candidate releases for Lucene 6.0.0.
As usual we'll refrain from making API changes in a minor release, but
we should start to sometimes try building against Lucene 6 to make
sure to use APIs which will live longer, if there's choice.
The most notable change is an entirely new strategy to handle numeric
fields; including overhauled APIs.
I guess Hibernate Search 6 will probably want to align with Lucene 6
and Hibernate ORM 6; only problem I see with that is I hope people
won't get used to these all being nicely aligned as it's probably not
sustainable as a rule.. just luck so far (although we managed that
with all of the 3.x, 4.x, 5.x and now 6 series of Hibernate Search!).
Both Lucene 6 and ORM 6 will require Java 8.
I'll update the Search roadmap to reflect this aim, as I assume there
won't be concerns?
While setting up my environment for hibernate.org and in.relation.to, I
noticed that there are broken links in the README... when we read it on
GitHub (the .adoc extension is missing). It works OK when we read it from
the website using http://hibernate.org/README/.
I expect most people to use GitHub to read this document and the other ones
related (docker/README.adoc, survival-guide.adoc).
I was thinking about adding these files to .awestruct_ignore so that we
don't generate website pages for them and fix them for GitHub browsing.
Anyone against it?
We have been having a few side discussions about plans for 6.0, and I
thought it would be a good idea to consolidate them together.
1. Incorporate the SQM work. Lots of pieces go into this:
1. Replacing the interpretation of HQL/JPQL and Criteria queries.
2. *Possibly* leveraging SQM to deal with entity operations
(load-by-id, merge, etc).
3. Improved Query contracts
4. Improved persister contracts (including addition of an "embeddable
5. Improved Type contracts
2. Extensions to JPA criteria based on SQM work(this is probably more on
ongoing 6.x task)
3. Baseline on Java 8
Is there anything else anyone wants to discuss getting included?
Another one I'd like to discuss is the consolidation of the hibernate-core
and hibernate-entitymanager modules into a single module (possibly renamed
hibernate-orm). There are a lot of reasons and benefits to doing this:
1. A major one would be the consolidation of "type systems". Hibernate
has org.hibernate.type.Type. JPA defines javax.persistence.Type. Now with
SQM we have a 3rd type system in play.
2. It is also the major hurdle to moving to being able to fully replace
the legacy criteria with JPA criteria. If Session and EntityManager (as
well as SessionFactory ad EntiytManagerFactory) were fully integrated then
Session would be able to build/handle JPA criteria queries.
3. Simplified HEM bootstrapping
There are also a few challenges to doing this consolidation of the
hibernate-core and hibernate-entitymanager modules. The big one tht stick
out in my head is event-listener with different behaviors between core and