That's an interesting problem that we started to scratch in the document oriented approach.
In the key/value pair, the underlying system has no notion of association. The table + column(s) mapping works great. 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. 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. I have a few questions for you Pawel. - 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? - 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? 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. 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. Pawel, I'd recommend you use collectionRole for your association name. Let me know if that works even in the bidirectional case. 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. Emmanuel On 28 mai 2012, at 22:34, Pawel Kozlowski wrote: > hi! > > I'm progressing on the implementation of the Neo4j integration for > Hibernate OGM and I think that I've bumped into a missing piece of > info when mapping associations. > > Let me explain: in Neo4j (in any grap database really) it would be > very natural to map an association of 2 entities as a relationship > among 2 nodes (where each node represents an entity). This was the > path I was taking but then I've realized that I'm probably missing a > piece of info that would allow me to connect 2 nodes together. > > Looking at the OGM docs and debugging I've realized that (at least > today) I've got only following pieces of info available in the > AssociationKey: > - table name for the association owning entity > - a set of column names / column values corresponding to a primary key > of the target entity. > > Moreover, 'columnNames' in AssociationKey got a predefined names in > form of [o:property name]_[t:pk_field1], [o:property > name]_[t:pk_field2] etc. (where 'o' stands for the owning entity and > 't' for the target one). > > What I would like to (ideally) do is to map an association as a Neo4j > relationship between 2 nodes (each node corresponding to an entity) > where the relationship would be named as [o:property name]. > Unfortunately I'm facing 2 issues: > > 1) I don't have access to EntityKey's of 2 ends of the association (or > at least I don't know how to access this info). I've noticed that > Emmanuel works on providing a valid EntityKey inside a AssociationKey > (https://github.com/emmanuelbernard/hibernate-ogm/tree/OGM-177) - I > guess it would solve half of my problems :-) > > 2) Naming strategy of column names in AssociationKey ([o:property > name]_[t:pk_field1]) makes it difficult to get a hand on a [property > name] - I would like to avoid splitting on '_' as it is very fragile. > > I'm still quite new to Hibernate OGM so I'm not sure if I'm > approaching the problem from the right angle. I would really like to > keep mapping as natural to Neo4j / graph DB way of thinking so I would > be grateful for any feedback. > > Cheers, > Pawel > _______________________________________________ > 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
