[OGM] Issue with a test and the new operation grouping infrastructure
by Guillaume Smet
Hi,
This is a follow-up of https://github.com/hibernate/hibernate-ogm/pull/767 .
So, in the PR, I commented the following test:
ManyToOneGlobalTest>ManyToOneTest.testRemovalOfTransientEntityWithAssociation
(the "ManyToOneGlobalTest>" part is important)
The test is a Redis one but the issue is a general one.
When running under the ManyToOneGlobalTest umbrella, the associations
are created as separate documents.
The behavior of the test is the following:
========================
=== Creation phase
Create a SalesForce with 2 SalesGuys associated.
The association is managed by SalesGuy.
It creates 4 documents:
SalesForce1
SalesGuy1
SalesGuy2
SalesForce1_SalesGuy navigational information
=== Let's delete the SalesForce1 entity
It removes the SalesForce1 document (note that SalesGuy.salesForce has
a @NotFound(action = NotFoundAction.IGNORE) annotation).
So we end up with having:
SalesGuy1
SalesGuy2
SalesForce1_SalesGuy navigational information [1]
=== Then we delete the 2 SalesGuy
SalesGuys1 removed
-> SalesForce_SalesGuy navigational information updated
SalesGuy2 removed
-> SalesForce1_SalesGuy navigational information removed as it is empty [2]
========================
In [1], we still have the navigational information for SalesForce1 <->
SalesGuys.
With the new grouping infrastructure, I don't save every operation to
the datastore as it's currently done. I have to store the Association
object somewhere to keep track of the association state so I store it
in OgmEntityEntryState in a Map<String, Association>, the key being
the role of the association, just next to the Tuple which has the same
purpose. It works perfectly well except that when we arrive at [2],
the OgmEntityEntryState for SalesForce1 is gone as the entity has been
removed in [1] so I can't access the OgmEntityEntryState of the entity
and so the association document is not removed (and thus the test
fails as it checks there isn't any entity/association left).
Gunnar proposed the idea of storing the inverse Associations in the
OgmEntityEntryState of the association owner. It's indeed one way to
solve the issue.
The issue with this approach is that we need to have the association
owner when we create the AssociationPersister and, while it's not a
problem for most of the cases, I don't see how I can do it in
OgmLoader#getResultSet. I posted a WIP patch here:
https://gist.github.com/gsmet/e18ccb7d3f3494bb334647e540d0d4d0.
Opinions, thoughts?
--
Guillaume
10 years
Question regarding HHH-10229
by Christian Beikov
Hey everyone,
I'd like to get HHH-10229 fixed as I can't workaround it. I prepared the
fix and a test(https://github.com/hibernate/hibernate-orm/pull/1558),
but I am not sure if that's the best way to do it.
Basically what I did is to check if an IdentNode is an alias to an
element collection and if so, resolve it to the element type when
requested from the select clause. This is very similar to what is
happening when a MapValueNode is used, in fact some of the code is copied.
When I later encounter that a map or index function is around it, I
resolve it as alias again.
Any comments?
Regards,
Christian Beikov
10 years
OpenJDK proposal: JDK 9 modules and reflection
by Emmanuel Bernard
Hi all,
Sanne kindly pointed out to me the latest proposal by the OpenJDK team
around JDK 9 module and how they would handle frameworks needing access
to non exported types (Hibernate, dependency injection, etc).
If you are remotely into JDK9, please read it and provide feedback.
http://mail.openjdk.java.net/pipermail/jpms-spec-experts/2016-September/0...
It's better than before for sure. It feels to me that most applications
(the core of it) will end up being a weak module for this to work
though. I'm not sure whether it is good or bad, at least a isolation
concious person has the choice.
export private some.package;
Is essentially equivalent to what you can do for a given package in Java
8.
What I am less clear about is what relation Hibernate * projects really
need with a module containing the entities. Do we still this proposal
still mandates to use
requires hibernate.entitymanager;
requires hibernate.core;
in the targeted module?
Or would this be a usable module
module foo.bar {
exports private com.foo.bar.model;
requires javax.jpa;
// requires hibernate.entitymanager/core; no longer needed thanks to export private?
}
Mark proposes that in a container (EE or anything controlling module loading
really), the container adds dynamically the addExports to the relevant
framework. But that looks like a solution to limit exports private
implications.
Comments?
Emmanuel
10 years
People need an Hibernate Search release to match ORM 5.2
by Sanne Grinovero
Hi all,
as you might be aware, ORM 5.2 made some rather radical internal work,
and the latest Hibernate Search releases aren't compatible.
So far, business as usual: we typically simply catch up on the next minor.
The problem is that normally Hibernate Search releases are time-boxed
- with us only merging new features when they are ready - so that we
can trigger a release as needed, as contingency required.
However currently we switched temporarily to a less desirable "we ship
when it's ready" as the Elasticsearch integration couldn't possibly be
developed by a single person in a feature branch, so in short we're
not in a position to "just release" it, as it's not ready and this
will take another month (optimistically). This would position
Hibernate Search 5.6 in September.
We'd also want to have WildFly users have a chance to use this new
Elasticsearch feature, which ties us to make this release compatible
with ORM 5.0 and 5.1.
So Hibernate ORM 5.2 users who need Hibernate Search will need to wait
for Search version 5.7, which in timelines would mean this fall.. way
too far ahead.
(I tried to figure out a way to make Search master compatible with
both, but that's just not possible: it's either/or, barring an
outrageous amount of work which I'd rather spend in finishing 5.6 and
move on do do the migration properly..)
On HSEARCH-2296 [1] James proposed we could already publish a 5.7 SNAPSHOT.
Assuming we can set the right expectations, what would you think of
this idea to branch a 5.7 already even though 5.6 isn't done?
We could even call it Alpha1 and tag appropriately. The goal is of
course to make sure people have at least something they can test with
and make progress while we put our stuff together.
The downside is of course that all remaining work on 5.6 will have to
be regularly rebased and applied to 5.7 too. Considering we won't do
any other changes on 5.7 I don't expect this to hurt too much.
Thanks,
Sanne
1 - https://hibernate.atlassian.net/browse/HSEARCH-2296
10 years
Lambda usage to run a code block in an isolated transaction
by Sanne Grinovero
Today porting some benchmark code to Hibernate ORM 5.2 I had several
difficulties around the fact that the code now needs to be different
depending on transactions being container managed or not.
My goal was to have a single benchmark test which I could compile once
and run in either JavaSE or CMT; with some help from Steve I figured
the necessary incantations out but ... it looks very unpractical.
One way is to use an isolation delegate, which looks like this:
final SessionImplementor session = (SessionImplementor) s;
session.getTransactionCoordinator().createIsolationDelegate().delegateWork(
new WorkExecutorVisitable() {
@ Override
public Object accept(WorkExecutor executor, Connection
connection) throws SQLException {
/// Some work with PreparedStatement on Connection..
}
}, true );
This worked fine for some raw SQL used for the benchmark
initialization, but in another case I'd prefer to use the Session API
rather than dealing with PreparedStatements and native connections;
it looks like we don't have an equivalent "run code in isolation" for
the Session ?
It would be great if I could just pass a lambda to a Session and have
this executed on a "child Session" in the scope of a "child
Transaction", or just start and commit a transaction if there isn't
one.
s.executeInIsolation( session -> session.save(...) );
So I'd expect that details like how to begin the transaction, how it
should be committed (or rolled back in case of exceptions), how to
lookup a TransactionManager, and especially how to not leak resources
should be handled for the user.
Obviously the inner Session instance is a different one than the
outer, so any data returned by this block should be considered
detached; maybe this limitation would be clearer if the method was
hosted on SessionFactory or StatelessSession instead?
Although it wouldn't necessarily have the limitations of a
StalessSession, and it would be nice to have the inner transaction
behave as a nested one when there's already one in the host Session.
Looking forward for comments and improvement ideas :)
Thanks,
Sanne
10 years
Usage of Session#getTransaction() being banned from the Hibernate Search code
by Sanne Grinovero
Since Hibernate ORM 5.2, the method getTransaction() on Session needs
to behave according to EntityManager spec, which implies that it has
to throw an exception in certain circumstances which depend on the
configuration.
Hibernate Search used this method in various places, for example to
integrate with the current transaction's events, or even to control
the transaction explicitly in the case of the MassIndexer.
Since we want Hibernate Search to work fine with Hibernate ORM no
matter what configuration is being used, we need to avoid invoking
this method.
The solution is extremely simple: use its SPI level replacement, which
is SessionImplementor#accessTransaction().
Unfortunately most of our Search/ORM tests happen to run without a
Transaction Manager so if you happen to use the old method, the tests
would pass and everything would seem fine - however your shiny new
feature would not work in certain configurations.
One solution to verify we're not using it, is to ban this method using
the "forbiddenapi" plugin:
- https://github.com/Sanne/hibernate-search/commit/a980ee5dca0c7a58dd79ba98...
A more comprehensive integration test would be to re-run all tests
from the Search/ORM using a proper JTA configuration; not rushing to
refactor our testsuite now since we have the forbidden-apis plugin but
opening a JIRA task for 5.7, as this version will support ORM 5.7:
- https://hibernate.atlassian.net/browse/HSEARCH-2344
Thanks,
Sanne
10 years
