Ticket #390 (closed Enhancement: wontfix)
Refactor storage layer
| Reported by: | jri | Owned by: | jri |
|---|---|---|---|
| Priority: | Major | Milestone: | Release 4.1 |
| Component: | DeepaMehta Standard Distribution | Version: | 4.0.13 |
| Keywords: | Cc: | dgf, Malte | |
| Complexity: | 8 | Area: | |
| Module: | deepamehta-core |
Description
In conjunction with #389 it turned out Neo4j MehtaGraph? doesn't suits anymore. That's because the Association Type and the Topic Type (of the related topic) are subject of indexing but currently not part of the MehtaGraph? model at all. Only the role types are.
Extending Neo4j MehtaGraph? by node types and edge types seems not an option. The original Neo4j MehtaGraph? concept was being a generic storage layer for mehta-graphs, to be usable by other applications as well, not only for DM. It turns out the generic approach conflicts with application-specific requirements.
Furthermore, the priority for the DM storage layer has meanwhile shifted from
- a DM-independant Neo4j-based mehta-graph persistence layer usable by other applications
to
- a DM-specific abstraction for which many implementations can exist, each one based on a different database product.
Focus of this ticket is:
- Removing the Neo4j MehtaGraph? dependency.
- Implementing the DeepaMehtaStorage? interface by the means of Neo4j directly, and thus removing the bridging layer (and its overhead). The storage implementation will be part of the DM Core module at first.
Later on (not addressed in this ticket) the storage implementation can be encapsulated in its own module, and allowing for alternate implementations.
