Good behaviour & pull requests
by Sanne Grinovero
Hi all,
I recently sent a pull request containing, among others, a very
specific paragraph of documentation.
This was merged with no other comment than a thank you, and I
appreciate both the speed and thanks.
BUT checking now after the release is done, as I am in need to refer
to this section, I see my paragraph was altered, and it's wrong, or
confusing at best.
That's not fair. It's nice and pragmatic that we all occasionally take
initiative and decide on some flexibility on the PR process, but
please please please let the PR author know when you decide to make
some changes so they get the opportunity to disagree.
Thanks,
Sanne
8 years, 3 months
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
8 years, 3 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
8 years, 3 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
8 years, 3 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
8 years, 3 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
8 years, 3 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
8 years, 3 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
8 years, 3 months
