When I started exploring this data set in the Github repository and on the website, I thought of a few different ways to model it as a graph. I could probably spend an entire post on that separately, but I’ll focus on what ended up being the current model.
To start, I went to the whiteboard and drew the Java version entities with diffs, and then basically created a tree of the different types of changes beneath that. As an example, I looked at a page like the one showing the delta between Java 16 and 17 to see how many nesting levels I might need and the types of differences we might see. Honestly, though, I didn’t look at every possible change type - I let Cypher (Neo4j’s query language) do some of the work here. I ended up with something along the lines of the image shown below.
I toyed quite awhile with the relationship names between the
Diff entities, and I’m still not super confident about the final versions (shown later). But, this was a good starting point to build my import statements.
I ended up just using Cypher for the import because it can be applied with any instance of Neo4j, and is accessible for a wide audience to replicate. You can copy/paste all of the contents of the java-version-import.cypher file directly to a Neo4j Browser UI and import everything exactly as I have it.
Once those Cypher statements complete, you can run
CALL apoc.meta.graph() in the Neo4j Browser to see the data model. It should look like the one shown below.
Now that we have our data model, we can run some queries and explore Java 17! Yay!