Ticket #390 (closed Enhancement: wontfix)

Opened 11 years ago

Last modified 11 years ago

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


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


  • a DM-specific abstraction for which many implementations can exist, each one based on a different database product.

Focus of this ticket is:

  1. Removing the Neo4j MehtaGraph? dependency.
  2. 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.

Change History

comment:1 Changed 11 years ago by jri

  • Status changed from new to accepted

comment:2 Changed 11 years ago by Jörg Richter

comment:3 Changed 11 years ago by jri

  • Status changed from accepted to closed
  • Resolution set to wontfix

Deprecated in favor of #391

Note: See TracTickets for help on using tickets.