Databases Reference
In-Depth Information
Figure 6-7. Logical view of the user-facing APIs in Neo4j
We discussed Cypher in some detail in
Chapter 3
. In the following sections we'll step
through the remaining APIs from the bottom to the top. Again, these APIs are meant
to be illustrative. Not all graph databases have the same number of layers, nor necessarily
layers that behave and interact in precisely the same way. Each API has its advantages
and disadvantages, which you should investigate so you can make an informed decision.
Kernel API
At the lowest level of the API stack are the kernel's
transaction event handlers
.
These
allow user code to listen to transactions as they flow through the kernel, and thereafter
to react (or not) based on the data content and lifecycle stage of the transaction.
Kernel Transaction Event Handlers
A typical use case for transaction event handlers is to prevent physical deletion of re‐
cords. A handler can be set up to intercept deletion of a node and instead simply mark
that node as logically deleted (or in a more sophisticated manner, move the node “back
in time” by creating timestamped archive relationships).
Core (or “Beans”) API
Neo4j's Core API is an imperative Java API that exposes the graph primitives of nodes,
relationships, and properties to the user. When used for reads, the API is lazily evaluated,
meaning that relationships are only traversed as and when the calling code demands
the next node. Data is retrieved from the graph as quickly as the API caller can consume
it, with the caller having the option to terminate the traversal at any point. For writes,
the Core API provides transaction management capabilities to ensure atomic, consis‐
tent, isolated, and durable persistence.
