Chapter 12. Data Refactoring with Neo4j

This chapter is dedicated to the evolution of your graph.

Your data model will evolve over time. It could be because the first time is not perfect, most probably because of evolving requirements. We will start with the simple cases and go through increasingly complex cases. 

We will be covering the following topics in the chapter:

• Capturing information of key pinpoints/locations
• Remodeling pinpoints/locations
• Extracting information from pinpoints/locations
• Adding and fetching locations

Preliminary step

You certainly know the proverb better to be safe than sorry and Murphy's law, don't you?

The advice is simple: back up your data! (See the Appendix, Tips and Tricks, for the ways to backup your server).

Before doing structural changes, you should play it safe. It is valid for all databases. Also, a backup procedure is in Schroedinger's state until validated.

Simple changes

I define simple changes as changes effecting individual nodes without impacting relations or other related nodes. 

Renaming

There is no renaming feature in Cypher but there is a procedure for that in APOC.

The sentence there is a procedure for that in APOC is almost a mantra in the Neo4j community.

The longer version ends with--if there isn't , ask Michael,  for Michael Hunger whom I already wrote about.

It is possible to rename labels, relations, node properties, and relation properties with APOC.

Currently, relations are named types so the procedures are as follows:

CALL apoc.refactor.rename.label(oldLabel, newLabel, [nodes])
CALL apoc.refactor.rename.type(oldType, newType, [rels])
CALL apoc.refactor.rename.nodeProperty(oldName, newName, [nodes])
or
CALL apoc.refactor.rename.typeProperty(oldName, newName, [rels])

You may optionally give a list of nodes or relations. Awesome.

Adding data

Adding data is enriching the current data model with new properties. This is rather safe. No risk...

Great changes

When great changes are coming, you have to be prepared. Being philosophical, one could say know where you are and know where you go.

Know your model

To know where you are is to know your actual model. A previous feature of the APOC plugin, showing your meta-model as a graph is now a default feature of Neo4j and Cypher:

CALL db.schema()

As it is an instant view of your schema, I advise you to save this representation of your schema:

How to export a view of the schema

Export both formats. You can print the PNG image to use as a basis for your new modeling, while the CSV lists all the properties.

 We will now see a panorama of the types of changes that you may have to perform.

Refactoring tools

To refactor our graph, we have two tools at our disposal. The first is standard Cypher and the second is APOC--in particular, the apoc.refactor package of procedures. Also mandatory is concentration and data backup, but you already know that.

Property to label

To add a label to a node based on a...

Consequences

There are two proverbs I like, which perfectly apply to our IT world:

With great power comes great responsibility .... 

To err is human, most catastrophes imply computers.

Refactoring is a high risk of damaging your graph by accident. It is possible to lose information by removing properties on nodes that have not had that information transformed. It also impacts the queries that you have already written for your applications. Hopefully, breaking changes will appear by running your unit tests, which I am sure you have written.

Performance may be impacted too, as shorter queries tend to execute more quickly; there is a cost to adding more relations in a query.

Summary

We saw how to modify our graph of data for the most common updates. Undoubtedly, this will be useful to cope with the evolutions of your data projects during their lifespan (may they live long and prosper).

In the next chapter, we will talk about clustering several Neo4j Enterprise servers. A new frontier!