[hibernate-dev] [OGM] [Neo4J] AssociationKey and missing info for associations mapping

[Pawel Kozlowski]

Hi Emmanuel, All,

Thnx for taking time looking into this, my comments below.

On Tue, May 29, 2012 at 3:31 PM, Emmanuel Bernard
<emmanuel at hibernate.org> wrote:

> In a Document approach, there is no (useful) notion of association either but one can gather a set of elements under a property name. This is useful for collection of embedded and collection of associated entities that one want to embed. But the property name under which we would set the collection is not property rendered in the table + column(s) approach. That's why associationKey has  getCollectionRole(); I wish I had a better approach but today that's what we've got.

While checking under debugger I can see that the 'collectionRole'
field is not filled in AssociationKey (it is null). I can observe this
with the master branch of https://github.com/hibernate/hibernate-ogm.
Is there any other repo / branch where the work on the collectionRole
is more advanced? Or am I missing sth here?

> In a graph approach, true associations are expressible in the system. So we both need some kind of association property name (which can be the collection role) and also a way to identify the entity being associated.

Exactly, this is my reasoning as well.

> - In Neo4J, is there a notion of (optional) schema where we would not need to repeat that we are linking from A to B in property foo?

Hmm, not sure if I'm reading you correctly here, but I'm not aware of
any such optional schema... Not sure if by A,B here you are referring
to node instances or node "classes". Because - as far as I'm aware -
in Neo4j you don't have any concept of a Node type. Node is just a
Node, it differs from other nodes only by:
- its internal id (really internal, assigned by Neo4j and not overradible)
- its properties
- its relations (associations)

> - Do you expect the same association name when linking A to B and B to A? In other words are associations (always) bidirectional and what's the (perf) cost of making them bidirectional?

If you've got a relationships among 2 nodes such a relationship has a
direction but it is actually possible to trawerse in both directions
(there shouldn't be any performance hit regarding the direction of
traversal). In short: Neo4j stores the info regarding the relationship
direction but those associations do behave as bidirectional when it
comes to traversing.

so yes, answering your question, I would expect the same association
name when linking A to B and B to A.

> We will need at some point to introduce the notion of @AssociationName to separate the object model from the association representation in document and graph datastores.

Hmm, ok, I'm not sure I can see imediatelly a need for the
@AssociationName. Let's assume I've got a User entity that has 2
OneToOne associations to an Address entity (say, stored in homeAddress
and workAddress fields). Given such object model I would map a user to
a Node, 2 addresses to a nodes and would have the following
relationships:

UserNode(id=user1)--homeAddress-->AddressNode(id=adress1)
UserNode(id=user1)--workAddress-->AddressNode(id=adress2)

Not sure if I'm making myself clear here, if not I can prepare a ghist
+ screen shoots from Neo4j editor to illustrate it better.

> I am not thrilled at the idea of giving you the owning and (set of) target EntityKey for each association but I don't see any better way. I think the target EntityKey is not too hard to construct but as mentioned on OGM-177 getting the owning one is going to be harder.

Yep, I kind of expected that you guys won't be thrilled by this as
this somehow 'breaks' the current 'table model'. At the same time I
believe that the mapping should be as natural for a given store as
possible.

> Pawel, I'd recommend you use collectionRole for your association name. Let me know if that works even in the bidirectional case.

This should work in the bidirectional case, just need to understand
why it is null in the current implementation. Do you have any idea
about what might be going on here?

> You can also explore the idea of filling up the EK of the target entity in AssociationKey. Let me know how hard that is. I will likely need to dive on this one but if you can explore a bit that will help.

OK, sure, will look into this to do preliminary investigations.

Once again, thnx for you input so far!

Cheers,
Pawel