pkg persistence - yshehab/SchoolRoomBooking GitHub Wiki

After considering ORM, we have decided to try a graph database with OGM.

Neo4j is a robust (fully ACID) transactional property graph database. Due to its graph data model, Neo4j is highly agile and blazing fast. For connected data operations, Neo4j runs thousand times faster than relational databases.

Embedded Neo4j (from The Graph Database)

In embedded mode, Neo4j runs in the same process as our application. Embedded Neo4j is ideal for hardware devices, desktop applications, and for incorporating in our own application servers. Some of the advantages of embedded mode include:

• Low latency
  • Because our application speaks directly to the database, there’s no network overhead.
• Choice of APIs
  • We have access to the full range of APIs for creating and querying data: the Core API, traversal framework, and the Cypher query language.
• Explicit transactions
  • Using the Core API, we can control the transactional life cycle, executing an arbitrarily complex sequence of commands against the database in the context of a single transaction. The Java APIs also expose the transaction life cycle, enabling us to plug in custom transaction event handlers that execute additional logic with each transaction.
• Named indexes
  • Embedded mode gives us full control over the creation and management of named indexes. This functionality is also available through the web-based REST interface; it is not, however, available in Cypher.

Here is a "Hello World" class using Embedded Neo4j.

Watch this video http://vimeo.com/77824636 and login with your facebook account to the guy_s cool website http://neographsearch.maxdemarzi.com/ to run Cypher queries on your facebook friends.

As the objects will be stored in a graph as nodes, we have two options for their relationships' schema:

1. Use the OGM default naming schema
   In this case the variable names will be used as relationship name. It is fairly simple and will use the naming of the relationships between the objects as they are coded in the business domain.
2. Provide a schema
   This provides more control over the direction of relationships and their names which will make the code nicely flows when traversing the graph.

I don't think we will need to traverse the graph that much -so far I can see a potential need for writing queries in two cases.

As we want to mostly deal with domain objects (i.e. less presence of OGM code), I recommend to start with the default of the OGM and change that if we need to.

This is a diagram with the relationships handled by the OGM (to compare, I have named the relationships in the visualisation snapshots.)

After adding few Member objects with relations to Name, Email and Address this is how neoclipse tool visualises the database at different depths.