neo4j and nodes: what is a node? is it really a DTO in sheeps clothing?

I have been using neo4j for awhile now and I think I have begun to realize that the Node class is really a data transfer object in disguise. Some applications can use it directly, and that's okay and you should because it is simpler to use than other options.

Because I need to have to perform other operations on nodes prior releasing them, I need a first-class DBObject type that allows me to use interceptors and various other processing schemes to meet the requirements of my application.

For example:
  • Lucene indexing: I need to create special external lucene full text indexing that uses quite a bit of the lucene engine. I need to manage that index in one place where the updates, adds and deletes occur.
  • Property change event: I need to send events when the properties change so that my UI can be updated appropriately.
  • For some properties on a node, I need typed access.
I could use a simple wrapper around a Node and access the Node's properties when I need to obtain a value. This is recommended in the neo4j manual. But a Node can only be read when it is a transaction and that can be very inconvenient.

I need something like the EntityManager support found in JPA. In other words, I need:
  • Create a dbobject, manipulate properties, and when I am ready, save it the db.
  • Create a dbobject that is not in the database and once saved, obtain the node id (good for the current session only).
That's why spring data neo4j does what it does to some extent. I do not need POJOs myself, but now I understand the value of the spring data neo4j layer, it adds some goodness that is missing otherwise.

But its clear that I need some type of thin layer that sits above nodes and abstracts out the underlying graph database. To keep the schema clean, I also need it to be key-value based.


Popular posts from this blog

zio layers and framework integration

typescript and react types

dotty+scala.js+async: interesting options