(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 <yo...@hibernate.org> Hibernate NoORM Team On 12 September 2016 at 17:31, Guillaume Smet <guillaume.s...@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@lists.jboss.org > https://lists.jboss.org/mailman/listinfo/hibernate-dev > _______________________________________________ hibernate-dev mailing list hibernate-dev@lists.jboss.org https://lists.jboss.org/mailman/listinfo/hibernate-dev