Announcement Announcement Module
No announcement yet.
Mapping EMF objects to Neo4j Page Title Module
Move Remove Collapse
Conversation Detail Module
  • Filter
  • Time
  • Show
Clear All
new posts

  • Mapping EMF objects to Neo4j

    As part of a university research project, we want to try Neo4j to store large instance models built in the Eclipse Modeling Framework as Neo4j graphs, query the graph and retrieve the result as EMF/POJO objects. We also want to modify the objects and update the graph accordingly.

    Obviously, mapping the objects to the Neo4j property graph data model requires some work. We created annotated (@NodeEntity) POJO clones of the EMF objects in our metamodel and used Spring Data Neo4j to map and save the instance model to Neo4j. This worked well but the load performance was slow.

    In the answer to, Michael Hunger pointed out that this is normal, as the API is not intended for mass inserts.

    My questions are: which of the following approaches should we take to achieve our goals? Are there any other. simpler ways to load EMF models to Neo4j and query?

    1. Our current approach: for the sake of simplicity we iterate through the EMF model twice. First clone the objects to annotated POJO objects, then set their references to to the appropriate POJO. Get a GraphRepository using Neo4jTemplate.repositoryFor(...) and save. Use Cypher through Spring Data to get the annotated POJO objects. This is pretty comfortable, unfortunately, loading the data is very slow.

    2. Map the EMF objects to the graph using the Neo4j core API and store the EMF UUIDs in the graph. Use Cypher through the Neo4j core API, get the UUIDs in the query and pick the resulted EMF objects accordingly. Mapping the EMF objects to the graph would ease the performance issues but requires lots of code. This approach does not use the Spring framework.

    3. Map the EMF objects to the graph but call template.postEntityCreation for each node and use Cypher through Spring Data. This requires the annotated objects and the code for loading the graph but seems to grant reasonable performance and comfort.


  • #2

    I'd say, do a quick spike to decide what's best for your use case. Also, profile and see which particular bits are slow.




    • #3
      Thanks, I think I'll use manual mapping supported by some code generation (Xtend2). Gabor