Tobias Ivarsson
Wed, 20 May 2009 06:28:31 -0700
On Wed, May 20, 2009 at 3:03 PM, Peter Haensgen <p.haens...@intershop.de>wrote:
> > If you can't copy them, because you have too many relationships, you > need to separate them into 2 groups somehow: "added" and "removed". > The "added" group could be just the plain relationship, the "removed" > group could be a property with an array with ID's of the removed > relationships. > > For determining the visible relationships, you could go back to the > first version and then build up a set where you add the "added" > relationships and remove the "removed" relationships, until you arrive > at the latest revision. This would reduce the amount of data, but needs > more navigation. > > Maybe you can also mix both approaches: if the "removed" list becomes > too large, create a complete copy which serves as new baseline for the > next modifications. Ah, thanks! This was a good suggestion for my system. Entities don't have a huge number of relationships, but change frequency can be quite high. I could introduce different types of versions, where one type would gather all live relationships. This change type would then be used for when relationships are removed. Thanks! > > > It all depends on your data and the frequency of changes which approach > is best. > > > > 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? > > Yes, there are only unidirectional relationships, like in Neo. No, relationships in Neo have a direction, but they may be traversed in any direction - both start node and end node "know about" the relationship. Thanks guys. I think I have enough ideas to implement this system now. If anyone has more ideas on the topic, please add them, this thread need not be considered dead just because the problem that sparked it is solved. Versioning is much more general than that. If we want to find a design pattern for versioning entities with Neo, we need the input from multiple implementations to be able to find the "best practice" (tying back to the first response in this thread here - Hi Peter Ferne). 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