(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
`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
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
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 <yo...@hibernate.org>
Hibernate NoORM Team
On 12 September 2016 at 17:31, Guillaume Smet <guillaume.s...@gmail.com>
> This is a follow-up of https://github.com/hibernate/hibernate-ogm/pull/767
> So, in the PR, I commented the following test:
> (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_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:
> SalesForce1_SalesGuy navigational information 
> === Then we delete the 2 SalesGuy
> SalesGuys1 removed
> -> SalesForce_SalesGuy navigational information updated
> SalesGuy2 removed
> -> SalesForce1_SalesGuy navigational information removed as it is empty 
> In , we still have the navigational information for SalesForce1 <->
> 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 ,
> the OgmEntityEntryState for SalesForce1 is gone as the entity has been
> removed in  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:
> Opinions, thoughts?
> hibernate-dev mailing list
hibernate-dev mailing list