CODEWITHSUNDEEP
database-designgraphneo4juuidgraph-databases
Mik378
Mik378

Reputation: 22191

Neo4j / Strategy to keep history of node changes

Let's assume a graph dealing with cars.
Each Car can evolve over time, and I need to keep track of those changes.
(in order to be able to track some inconsistency of evolution etc...)

I thought about implementing a copy-on-write mechanism (like LinkedIn seems to do), meaning creating a complete new Car node each time one of the Car's properties changes.

I would end up with a graph like this:

(Ferrari)-[:CURRENT]->(V3)-[:PREVIOUS]->(V2)-[:PREVIOUS]->(V1)

I'm specifically interested in retrieving the most current version, so it would sound good.

However, how to deal with the initial Car UUID?

My Car's UUID (that is an indexed property to ease queries) is auto-generated through a library (Apache).
I imagine that if I keep the same initial UUID for each Car version, this might lead to some conflict: "Retrieve the Ferrari whose UUID is 123" => returning more than one result.. 3 results if 3 versions.

Is it safe and efficient to generate a new brand UUID for each version?

Thus, I'm aware than in this case, the only way to retrieve a particular version would then be to traverse the concerned portion of graph until the correct one, and not counting on a simple query on the initial UUID; that still seems very efficient and easy with a simple Cypher query.

I want to keep a generated UUID since having potential "guessable" REST URL (using resource's UUID so) is not advisable.
Indeed, I could have an UUID being the combination between the Car model and its version, but it seems not enough "safe" with a visibility on my URLS. Any malicious person could easily manage to retrieve an older version just by changing the URL.

Upvotes: 3

Views: 2010

Answers (1)

cybersam
cybersam

Reputation: 67019

You should have 2 types of nodes (with different labels) -- Car nodes (like "Ferrari" in your question) and CarVersion nodes (like the Vn nodes). Only the Car nodes should contain the UUID. All the other car data should go in the CarVersion nodes.

Also, to ensure the UUIDs are unique and to make getting a specific Car node faster, you can create a uniqueness constraint on the UUID property of your Car nodes.

Upvotes: 6

Related Questions