8:31 a.m.
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(a)lists.jboss.org
https://lists.jboss.org/mailman/listinfo/hibernate-dev