[Neo] Design pattern for versioned entities

Peter Haensgen P.Haensgen at intershop.de
Tue Apr 27 10:48:39 CEST 2010


Hi,

I have my own transaction implementation that is associated with the current thread. Transactions have a dictionary to hold arbitrary objects (such as revision objects) as "transactional context". Additionally, lifecycle listeners can be registered that can take action before / after begin / commit / rollback. Actually, it is just a wrapper around an underlying transaction from a persistence backend like Neo.

The revision objects are simply persistent objects that will be created on the first modification of a versioned object during a transaction. All touched objects will be registered at the revision, and on commit everything will be stored in the database.

regards,
Peter


> -----Original Message-----
> From: Georg M. Sorst [mailto:georgsorst at gmx.de]
> Sent: Montag, 26. April 2010 18:00
> To: user at lists.neo4j.org
> Cc: Peter Haensgen
> Subject: Design pattern for versioned entities
> 
> Hi Peter,
> 
> sorry to pick up this old thread, but you mentioned that in your system
> revisions are automatically created with every transaction. How do you
> do this? Hooks, aspects, weaving, magic?
> 
> Thanks and best regards,
> Georg
> 
> 
> > 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
> >
> >
> >> Anyone have an idea on how to model the history management in a case
> >> like this? You don't need to put too much focus on the actual
> >> structure, I just want to get at a structure for capturing the change
> >> history for the relationships in between entities.
> >>
> >> Thanks,
> >> --
> >> Tobias Ivarsson <tobias.ivarsson at neotechnology.com>
> >> Hacker, Neo Technology
> >> www.neotechnology.com
> >> Cellphone: +46 706 534857
> >> _______________________________________________
> >> Neo mailing list
> >> User at lists.neo4j.org
> >> https://lists.neo4j.org/mailman/listinfo/user
> 
> 
> --
> Georg M. Sorst
> Dipl. Inf. (FH)
> 
> Ignaz-Harrer-Str. 13 / Top 19
> 5020 Salzburg
> Österreich
> 
> Tel: +43 (0)650 / 53 47 200


More information about the User mailing list