ci@hibernate.org vs jenkins@hibernate.org
by Sanne Grinovero
All,
in various build configuration on ci.hibernate.org, it's using an
email alias "jenkins(a)hibernate.org".
Please use "ci(a)hibernate.org" instead, as the other one triggers
errors being sent to me in large volumes..
I've tried to get rid of them myself over time, but it seems you all
are fighting back on that when updating / creating new jobs :)
So the right email to use is:
ci(a)hibernate.org
thanks,
Sanne
9 years, 9 months
[Hibernate Search] Validating the Sort field
by Sanne Grinovero
A forums user asked why we don't validate the Sort field being set on
a FullTextQuery.
I've tried to summarize some of the reasons of why it's a complex
thing, still it's something worth considering.
Let's keep it in mind as yet another reason to try intercept which
fields are being written by custom FieldBridge instances?
Considering the special needs of a Sort field - being unique, being
fieldcacheable/documentValues enabled, maybe we should even consider
that adding them should have its own API, maybe even dedicated mapping
annotations.
Or other ideas very welcome.
https://forum.hibernate.org/viewtopic.php?f=9&t=1038601
Thanks,
Sanne
9 years, 9 months
New testing utility for the Logger
by Sanne Grinovero
Hi all,
since we recently had some issues to solve with the general theme
"verify X will not be logged", or sometimes we need the opposite: to
make sure that something *is* logged, I've abused a new feature of
JBoss Logger to make it easier to test.
Details on the PR:
- https://github.com/hibernate/hibernate-orm/pull/906
I was hoping to use it in other projects too but the "catch" section
explains why that's not going to work yet, so I'd suggest start
benefiting from it in ORM 5 and then see how it evolves.
Happy logging :)
Sanne
9 years, 9 months
Strange issue massindexer and classbridge
by Marc Schipperheyn
Hi,
I just wanted to share a strange issue I had w the massindexer and a
classbridge where a whole class of entities was not being indexed by the
massindexer (Hibernate Search 5.1).
The entity in question was part of an inheritance hierarchy.
Something like
BaseComment
Comment
Post
RSSPost
I noticed that only the "Post" entities were missing from the index after
running the massindexer against BaseComment. Tried various times.
Any new entity entered would end up in the index correctly.
I finally removed a ClassBridge I use on that entity and restarted.
MassIndexer then worked correctly. And continued to work correctly after
restarts even w the classbridge active again.
I have been switching between Hibernate 4.x and 5.1 regularly and
re-indexing every time without manually cleaning the index directories.
Perhaps this had something to do with it.
Cheers,
Marc
9 years, 9 months
JTA synchronizations on WildFly
by Gunnar Morling
Hi,
I'm trying to perform a specific action upon transaction rollback.
Assuming this could be done using a custom
javax.transaction.Synchronization, I tried to register a synchronization as
follows:
TransactionImplementor transaction = ...; // e.g. a CMTTransaction
transaction.registerSynchronization( new MySync() );
And indeed beforeCompletion() is invoked as expected. But afterCompletion()
never is. I debugged this a bit on WildFly and observed the following:
* Hibernate ORM registers RegisteredSynchronization with JTA.
RegisteredSynchronization manages (indirectly, through
TransactionCoordinator, SynchronizationRegistry etc.) those
synchronizations added through o.h.t.Transaction.registerSynchronization()
* WildFly (specifically, TransactionUtil [1]) registers its own
SessionSynchronization
for closing the entity manager/session
Now that second synchronization is called first, closing the session. Upon
SessionImpl#close(), the SynchronizationRegistry is cleared. Then when
afterComplection() is called on RegisteredSynchronization afterwards, any
previously registered delegate synchronizations are gone already and thus
do not get invoked.
I believe I found a workaround for my case by registering my
synchronization through JtaPlatform#registerSynchronization() (which
registers it with the actual JTA transaction).
My questions are:
* Is this behaviour expected?
* Is the work-around of doing the registration via JtaPlatform viable or
are there any drawbacks which I'm not aware of?
Thanks,
--Gunnar
[1]
https://github.com/wildfly/wildfly/blob/master/jpa/src/main/java/org/jbos...
9 years, 9 months
Jira issues
by Hardy Ferentschik
Hi,
I seem to have problems with Jira atm. If I select a link which refers to a specific version
(eg https://hibernate.atlassian.net/projects/OGM/versions/19251), I keep getting a 500 error
with the message "Sorry, we had some technical problems during your last operation."
It does not seem to matter which project or releases vs unreleased version.
Do you guys have the same problem? Any ideas on what's going on?
--Hardy
9 years, 9 months
DefaultLockEventListener cascading
by Mihalcea Vlad
Hi,
While investigating how Lock Cascading works, I realized that the lock "scope" is only applied for detached entities.
Object entity = source.getPersistenceContext().unproxyAndReassociate( event.getObject() );
//TODO: if object was an uninitialized proxy, this is inefficient,
// resulting in two SQL selects
EntityEntry entry = source.getPersistenceContext().getEntry(entity);
if (entry==null) {
final EntityPersister persister = source.getEntityPersister( event.getEntityName(), entity );
final Serializable id = persister.getIdentifier( entity, source );
if ( !ForeignKeys.isNotTransient( event.getEntityName(), entity, Boolean.FALSE, source ) ) {
throw new TransientObjectException(
"cannot lock an unsaved transient instance: " +
persister.getEntityName()
);
}
entry = reassociate(event, entity, id, persister);
cascadeOnLock(event, persister, entity);
}
upgradeLock( entity, entry, event.getLockOptions(), event.getSession() );
If an entity is already attached, the Lock will only be applied to the request entity.
If the lock request entity is detached, then it will be:
- re-associated
- and the lock cascade will be propagated
The Cascade lock action looks like this:
LockMode lockMode = LockMode.NONE;
LockOptions lr = new LockOptions();
if ( anything instanceof LockOptions ) {
LockOptions lockOptions = (LockOptions) anything;
lr.setTimeOut( lockOptions.getTimeOut() );
lr.setScope( lockOptions.getScope() );
if ( lockOptions.getScope() ) {
lockMode = lockOptions.getLockMode();
}
}
lr.setLockMode( lockMode );
session.buildLockRequest( lr ).lock( entityName, child );So, if I specify a "scope" lock request I can propagate the lock to all child association (configured with CascadeType.ALL or CascadeType.LOCK):
Query:{[select id from Comment where id =? for update][1]}
Query:{[select id from Comment where id =? for update][2]}
Query:{[select id from PostDetails where id =? for update][1]}
Query:{[select id from Post where id =? for update][1]}
Shouldn't this logic be consistent for both attached and detached entities?
The test is available on GitHub:
https://github.com/vladmihalcea/hibernate-master-class/blob/master/core/s...
Vlad Mihalcea
9 years, 9 months
Scanning and META-INF/orm.xml
by Steve Ebersole
Anyone remember why META-INF/orm.xml is handled specially in scanning?
I am having some trouble locally with scanning matching multiple sources
named META-INF/orm.xml and am trying to understand the reason we do what we
do here.
9 years, 9 months
