Hi Peter, The separation of identity and version of objects is a good point.
The way you have modeled things, are all active relationships at a particular version present at that version node, or is the set of relationships made up from all version nodes all the way back to the first version of an object. If all relationships are present at each version: do you then create relationships from the version nodes of both objects? Or perhaps all relationships are unidirectional in your system? If the relationships are the sum of all relationships up to a given version: how do you model deleted relationships? Consider the scenario: Two VersionedObjects: a and b. You want to create a bidirectional relationship in between these objects. Let a.v represent the new ObjectVersion for a, and b.v represent the new ObjectVersion for b, a.i the identity for a and b.i the identity for b. As far as I can tell you will need to create two relationships here: one for each direction: a.v --> b.i b.v <-- a.i And if you want to be able to handle removal of relationships you will have to copy both of these relationships to each new version, for as long as they remain. If you have a better way of modeling this, please let me know! Thanks, Tobias On Wed, May 20, 2009 at 10:54 AM, Peter Haensgen <p.haens...@intershop.de>wrote: > Hi, > > I have also built some versioning concept on Neo before. > > Essentially, my solution is based on two kinds of objects: > > - VersionedObject represents the identity of something. It references > ObjectVersions. > - ObjectVersion represents a version of the object, there can be many > and they point to their previous version for easier lookup > - an ObjectVersion contains the properties. If there are relationships, > they always point from an ObjectVersion to the target VersionedObject > - ObjectVersions belong to Revisions, each revision has a revision > counter and additional information (who changed what when and why). > - there is a global object that holds the current revision counter > > In my system, revisions are created automatically with every transaction > commit, so the actual versioning is completely hidden from the developer > that works with the domain objects. > > Using the revision counter, you can easily select arbitrary versions: > - for latest version, take the ObjectVersion with the maximum counter > - for some historic version, take the ObjectVersion with the maximum > counter that is smaller or equal the wanted revision counter. > > New object version are created on every change of a versioned object, > e.g. by setting a property or by creating a relationship. If the object > had an existing version before, the properties and relationships will be > copied to the new version. > > I have used this concept to build both a linear history of objects and a > more complex versioning system with branches. If you need branches, you > need some more things to consider, but it can be done as well. > > > HTH, > Peter -- 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
