2:56 a.m.
(Don't know what's the status of this, since it's been discussed on IRC,
but jumping in just in case)
I tend to agree with Gunnar that storing the association on the owning side
of the association seems like a good idea. At least with an external point
of view, it seems like the right choice, but I may be missing some details.
As for the specifics of the implementation, I just stumbled upon
`org.hibernate.ogm.persister.impl.BiDirectionalAssociationHelper`.
`getInverseCollectionPersister(OgmCollectionPersister)` and
`getInverseAssociationKeyMetadata(OgmEntityPersister, int)` may help... ?
All these methods suffer from a limitation: the current implementation will
only work with non-inverse collection persisters. **But** I wonder if it's
a limitation of the current implementation (we can't do more) or an
arbitrary limitation added on purpose (we don't want to do more).
For instance, in `getInverseCollectionPersister(OgmCollectionPersister)`,
we might think that the element persister used to get the reverse side is
null for inverse association. But from what I see in
`org.hibernate.persister.collection.AbstractCollectionPersister.AbstractCollectionPersister(Collection,
CollectionRegionAccessStrategy, PersisterCreationContext)` (line 315), the
element persister is always non-null regardless of whether the collection
persister is on the owning or the inverse side, provided it's not an
`@ElementCollection`.
Anyway, what I'm trying to say is:
`org.hibernate.ogm.persister.impl.BiDirectionalAssociationHelper` might not
help as it is now, but it's probably a good starting point.
Yoann Rodière <yoann(a)hibernate.org>
Hibernate NoORM Team
On 12 September 2016 at 17:31, Guillaume Smet <guillaume.smet(a)gmail.com>
wrote:
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.testRemovalOfTransientEntityWi
thAssociation
(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
_______________________________________________
hibernate-dev mailing list
hibernate-dev(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev