Preparing to release 5.2.11
by Gail Badner
I'm getting ready to release 5.2.11. Please do not push any commits to
master branch until I announce the release.
Thanks,
Gail
6 years, 7 months
[SEARCH] Code style - imports
by Yoann Rodiere
Hello all,
I just noticed that our IDEA codestyle configuration files have specific
rules about how to organize imports, whereas the Eclipse ones don't.
The most noticeable difference: organizing imports in Eclipse puts static
imports at the top, while in IDEA they end up at the bottom. But there are
other differences.
The Hibernate ORM codebase doesn't seem affected by these inconsistencies
(probably because most people working on it use IDEA), but in Hibernate
Search we've already reached the point where half of our files follow one
convention, and the other half follows the other.
What's annoying here is not the inconsistencies themselves (I could live
with that), it's more that in the long run we'll end up with tons of
unnecessary changes in our commits, due to one person using IDEA to edit a
file last edited with Eclipse, and vice-versa.
To make the matter worse, Eclipse is not as flexible as IDEA, and we cannot
configure Eclipse to match the IDEA style exactly. In particular, we cannot
configure where the static imports must go: they will always go to the top (
https://bugs.eclipse.org/bugs/show_bug.cgi?id=304415).
I can see two ways out, each with its own drawbacks:
- Switch to the "Eclipse" style, and create a Search-specific IDEA code
style configuration, with static imports at the top. We won't be consistent
with Hibernate ORM, though.
- Switch to the "IDEA" style, and create a Search-specific Eclipse code
style configuration, as close as the IDEA style as possible. As I said
above, automatic import organizing in Eclipse will never follow this style
exactly, so it's likely to make organizing imports in Eclipse quite
painful. We could add checkstyle rules to make sure we strictly follow the
style even in Eclipse.
WDYT?
Yoann Rodière
Hibernate NoORM Team
yoann(a)hibernate.org
6 years, 7 months
ORM 5.2 issue with getInterceptor() not being a true getter
by Guillaume Smet
Hi,
Note to Gail: this is potentially a blocking issue for 5.2.11 for the OGM
upgrade (I thought it was a bug in OGM but apparently, it's an issue with
ORM).
In 5.2 SessionImpl, we now use getInterceptor() instead of accessing the
interceptor field directly because the field has been moved to
AbstractSharedSessionContract.
See for instance the change made here in afterTransactionCompletion():
https://github.com/hibernate/hibernate-orm/blame/master/hibernate-core/sr...
I think this is an issue as getInterceptor() is not a simple getter but is:
@Override
public Interceptor getInterceptor() {
checkTransactionSynchStatus();
return interceptor;
}
protected void checkTransactionSynchStatus() {
pulseTransactionCoordinator();
delayedAfterCompletion();
}
Thus calling the pulse() method of the TransactionCoordinator, triggering
an implicit join whereas we're in the afterTransactionCompletion() phase.
This is an issue for us as the pulse() method of our TransactionCoordinator
creates Neo4j transactions so when the getInterceptor() method is called in
afterTransactionCompletion(), we create a new Neo4j transaction.
So 2 questions:
- should we really call checkTransactionSynchStatus(); in getInterceptor()?
If feels a bit weird.
- if so, I think we should have a true protected getter (interceptor()
following Steve's convention?) to avoid SessionImpl "pulsing" the
transaction coordinator when accessing the interceptor.
Thanks for your feedback!
--
Guillaume
6 years, 7 months
Hibernate OGM 5.2 Alpha1 release
by Davide D'Alto
HIbernate OGM 5.2 Alpha1 is ready.
The first thing you will notice in this release is that several
dialects are not part of the core project anymore. We decided to focus
our work on the Infinispan, Neo4j and MongoDB dialects.
Highlights of the release:
- Fixed bugs related to polymorphic hierarchies
- Improved query performance in Neo4j
- Infinispan Remote dialect via Hot Rod now supports operation grouping
- Removed Fongo dialect
- Support map-reduce and distinct operations in MongoDB using the
MongoDB CLI query language
All the details in the blog post:
http://in.relation.to/2017/09/11/hibernate-ogm-5-2-Alpha1-released/
Thanks,
Davide
6 years, 7 months
Problems with PreparedStatementSpyConnectionProvider
by Mark Rotteveel
I have run into a peculiar problem with
PreparedStatementSpyConnectionProvider, the tests that use it fail for
Firebird (and Jaybird 3) for reasons I don't understand.
As far as I can tell from debugging, in tests that use this class, the
statement misbehaves and instead of executing parts of its
implementation, the bytecode modifications applied to the statement by
PreparedStatementSpyConnectionProvider suddenly return a value from a
previous execution, which then causes an exception or other invalid
behavior because it is an incorrect value for the current execution path.
Has anyone seen this before, and what can I do to address this?
Mark
--
Mark Rotteveel
6 years, 7 months
Are the tests in the documentation module expected to run on MySQL only?
by Mark Rotteveel
Are the tests in the documentation module expected to run on MySQL /
MariaDB only? Or are they expected to run on all databases?
The test org.hibernate.userguide.mapping.basic.SubselectTest is failing
on Firebird, because it has the following subselect:
@Subselect(
"select " +
" a.id as id, " +
" concat(concat(c.first_name, ' '), c.last_name) as clientName, " +
" sum(at.cents) as balance " +
"from account a " +
"join client c on c.id = a.client_id " +
"join account_transaction at on a.id = at.account_id " +
"group by a.id, concat(concat(c.first_name, ' '), c.last_name)"
)
Firebird doesn't have a concat function. According to the version
history, this test previously used the SQL standard concat operator
'||', but this was changed in May with the commit comment "Fix test
failing on MariaDB".
I am surprised that this change wouldn't be failing on other databases
either (unless most of them define a concat function next to supporting
the || operator).
To fix this database independently, it would need to be changed to use
the JDBC concat function escape:
@Subselect(
"select " +
" a.id as id, " +
" {fn concat({fn concat(c.first_name, ' ')}, c.last_name)} as
clientName, " +
" sum(atr.cents) as balance " +
"from account a " +
"join client c on c.id = a.client_id " +
"join account_transaction atr on a.id = atr.account_id " +
"group by a.id, {fn concat({fn concat(c.first_name, ' ')},
c.last_name)}"
)
However, JDBC function escape are (almost) never used in Hibernate
tests, so I wonder if this would need to be handled elsewhere.
What to do? Do I ignore the documentation tests, add an exception for
Firebird or create a pull request with the above change, or something else?
--
Mark Rotteveel
6 years, 7 months
CDI / ORM / WildFly / Search integration plumbing
by Sanne Grinovero
Hi all,
In Hibernate Search we have a snippet of code doing:
private static BeanManager getBeanManager(Map<?, ?> configurationValues) {
return (BeanManager) configurationValues.get(
AvailableSettings.CDI_BEAN_MANAGER );
}
This used to work on WildFly 10 - even if we were to override the
Hibernate ORM version to 5.2.
By runnning the same integration test on WildFly 11 I'm now getting a
ClassCastException as the returned instance is of type
`org.jboss.as.jpa.hibernate5.HibernateExtendedBeanManager`, which does
implement `org.hibernate.jpa.event.spi.jpa.ExtendedBeanManager` but
does not implement the standard
`javax.enterprise.inject.spi.BeanManager` interface.
I'm unsure if this is a bug in the Search code or a misunderstanding
between the WildFly / ORM integration?
This javadoc seems relevant:
/**
* Used to pass along the CDI BeanManager, if any, to be used.
*/
String CDI_BEAN_MANAGER = "javax.persistence.bean.manager";
or should I interpret this property as meant only for "write" purposes
into the ORM configuration? I suppose it's unexpected that we attempt
to retrieve this as well.
Thanks,
Sanne
6 years, 7 months
Moving Java Forward Faster
by Rory O'Donnell
Hi Sanne,
Oracle is proposing a rapid release model for Java SE going-forward.
The high points are highlighted below, details of the changes can be
found on Mark Reinhold’s blog [1] , OpenJDK discussion email list [2].
Under the proposed release model, after JDK 9, we will adopt a strict,
time-based model with a new major release every six months, update
releases every quarter, and a long-term support release every three years.
The new JDK Project will run a bit differently than the past "JDK $N"
Projects:
- The main development line will always be open but fixes, enhancements,
and features will be merged only when they're nearly finished. The main
line will be Feature Complete [3] at all times.
- We'll continue to use the JEP Process [4] for new features and other
significant changes. The bar to target a JEP to a specific release will,
however, be higher since the work must be Feature Complete in order to
go in. Owners of large or risky features will be strongly encouraged to
split such features up into smaller and safer parts, to integrate
earlier in the release cycle, and to publish separate lines of
early-access builds prior to integration.
The JDK Updates Project will run in much the same way as the past "JDK
$N" Updates Projects, though update releases will be strictly limited to
fixes of security issues, regressions, and bugs in newer features.
Related to this proposal, we intend to make a few changes in what we do:
- Starting with JDK 9 we'll ship OpenJDK builds under the GPL [5], to
make it easier for developers to deploy Java applications to cloud
environments. We'll initially publish OpenJDK builds for Linux/x64,
followed later by builds for macOS/x64 and Windows/x64.
- We'll continue to ship proprietary "Oracle JDK" builds, which include
"commercial features" [6] such as Java Flight Recorder and Mission
Control [7], under a click-through binary-code license [8]. Oracle will
continue to offer paid support for these builds.
- After JDK 9 we'll open-source the commercial features in order to make
the OpenJDK builds more attractive to developers and to reduce the
differences between those builds and the Oracle JDK. This will take some
time, but the ultimate goal is to make OpenJDK and Oracle JDK builds
completely interchangeable.
- Finally, for the long term we'll work with other OpenJDK contributors
to establish an open build-and-test infrastructure. This will make it
easier to publish early-access builds for features in development, and
eventually make it possible for the OpenJDK Community itself to publish
authoritative builds of the JDK.
Questions , comments, feedback to OpenJDK discuss mailing list [2]
Rgds,Rory
[1]https://mreinhold.org/blog/forward-faster
[2]http://mail.openjdk.java.net/pipermail/discuss/2017-September/004281.html
[3]http://openjdk.java.net/projects/jdk8/milestones#Feature_Complete
[4]http://openjdk.java.net/jeps/0
[5]http://openjdk.java.net/legal/gplv2+ce.html
[6]http://www.oracle.com/technetwork/java/javase/terms/products/index.html
[7]http://www.oracle.com/technetwork/java/javaseproducts/mission-control/i...
[8]http://www.oracle.com/technetwork/java/javase/terms/license/index.html
6 years, 7 months
