On Tue, May 19, 2009 at 8:36 PM, Martin Kleppmann <mar...@eptcomputing.com>wrote:
> 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. Cool! As I said I had the feeling that there would be more people than myself modeling change over time. Since you are planning to publish your code under AGPL on github, do you mind me asking what the system you are building is doing? 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. :-) That makes a lot of sense! Good input. > > 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. Good observation. > > 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. I would like it if I could model each entity as one node, but if it makes things more manageable to model it as more than one node, then I will do that. > 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.) This sounds like a good way to model things. In my system it is more common to to change / add / remove the relationships than the entities. So perhaps I need to introduce a relationship indirection to be able to do the same thing for relationships in my system. ie let each relationship in the model be represented by two relationships with an intermediate node with your suggestion for history management. > 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 gut feeling is that you will make things complicated, with an explosion in the number of relationships for the target nodes, if you copy the relationships. Good input Martin, thanks. Let me know if you have more ideas. I'll keep updating this thread with my progress on the topic. To the rest of you: all ideas are welcome, any input is good to get, please chime in! Cheers, -- Tobias Ivarsson <tobias.ivars...@neotechnology.com> Hacker, Neo Technology www.neotechnology.com Cellphone: +46 706 534857 _______________________________________________ Neo mailing list User@lists.neo4j.org https://lists.neo4j.org/mailman/listinfo/user
