On 19 May 2009, at 16:47, Tobias Ivarsson wrote: > I feel that this is something that would occur in more applications, > so I > thing that it would be a good idea to come up with, and document, a > design > pattern for how to model different versions of entities in Neo4j.
As it happens, this is exactly what I have also been trying to do today! My application also relies on having a version history of entities. On 19 May 2009, at 18:17, Tobias Ivarsson wrote: > A VCS is one of the most simple cases of versioned entities, simply > because > it is a DAG. The problem with the system I am designing at the > moment is > that the versioned entities here are not structured as a DAG. There > *will* > be cycles in between entities. I think that it makes sense to (conceptually) separate the history graph from the data model graph. The data model will, in general, probably have cycles -- that's why we're using a graph database. :-) However, the version history of a particular entity will always be a DAG (unless you have a time machine which allows you to create loops in causality). And if you don't need merges (but instead can reject an update if it is based on a version which is not the latest), the version history just becomes a tree. The question is, what is an "entity" for the purposes of your application? For my application I am probably going to assume that an entity is modelled by just one Neo node and its properties. To update an entity, I create a new node with all the required properties and create a "replaces entity" relationship to its previous version. To delete an entity, I create a new empty node with no properties and create a "deletes entity" relationship to the previous version. (This allows deleted entities to be resurrected if necessary.) I'm not yet sure whether it is a good idea to copy the model relationships of an entity node when it is replaced with a new version. If relationships are not copied, you need to search each entity's version graph when traversing the model graph, and it's not obvious how to represent deleted relationships. If relationships are copied, you need to make sure that you only visit the latest version, not all versions, when visiting the graph. Your opinions are welcome. My code will go on Github under AGPL when it's a bit more presentable. I'm writing it in Scala and setting it up as a template for new Neo4j applications written in Scala, using Maven to build and Jersey for a JSON/XML REST API. Cheers Martin -- Martin Kleppmann Managing Director, Ept Computing Ltd. Web: http://www.eptcomputing.com Blog: http://www.yes-no-cancel.co.uk Twitter: http://twitter.com/martinkl _______________________________________________ Neo mailing list User@lists.neo4j.org https://lists.neo4j.org/mailman/listinfo/user
