[hibernate-dev] [OGM] Issue with a test and the new operation grouping infrastructure

[Yoann Rodiere]

(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 at hibernate.org>
Hibernate NoORM Team

On 12 September 2016 at 17:31, Guillaume Smet <guillaume.smet at 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 at lists.jboss.org
> https://lists.jboss.org/mailman/listinfo/hibernate-dev
>