Rename

Procedures set for renaming labels, relationship types, nodes and relationships' properties. They return the list of eventually impacted constraints and indexes, the user should take care of.

The available procedures are described in the table below:

call apoc.refactor.rename.label(oldLabel, newLabel, [nodes], config)

rename a label from 'oldLabel' to 'newLabel' for all nodes. If 'nodes' is provided renaming is applied to this set only

call apoc.refactor.rename.type(oldType, newType, [rels], config)

rename all relationships with type 'oldType' to 'newType'. If 'rels' is provided renaming is applied to this set only

call apoc.refactor.rename.nodeProperty(oldName, newName, [nodes], config)

rename all node’s property from 'oldName' to 'newName'. If 'nodes' is provided renaming is applied to this set only

call apoc.refactor.rename.typeProperty(oldName, newName, [rels], config)

rename all relationship’s property from 'oldName' to 'newName'. If 'rels' is provided renaming is applied to this set only

As the collection of data is processed in batch via apoc.periodic.iterate these procedures support the following config parameters:

Table 1. Config
name	type	default	description
batchSize	Long	10000	run the specified number of operation statements in a single tx - params: {_count, _batch}
parallel	boolean	true	run operation statements in parallel (note that statements might deadlock if conflicting)
retries	Long	0	if the operation statement fails with an error, sleep 100ms and retry until retries-count is reached - param {_retry}
batchMode	String	"BATCH"	how data-driven statements should be processed by operation statement. Valid values are: * "BATCH" - execute operation statement once per batchSize. Operation statement is prefixed with the following, which extracts each field returned in the data-driven statement from the `$_batch` parameter: [source,cypher] ---- UNWIND $_batch AS _batch WITH _batch.field1 AS field1, _batch.field2 AS field2 ---- * "SINGLE" - execute operation statement one at a time * "BATCH_SINGLE" - execute operation statement once per batchSize, but leaves unpacking of batch to the operation statement. The operation query can access the batched values via the `$_batch` parameter.
concurrency	Long	50	number of concurrent tasks are generated when using `parallel:true`

Example Usage

The examples below will help us learn how to use these procedures.

The following creates a graph contains nodes with the label Engineer connected by COLLEAGUES relationships:

CREATE (mark:Engineer {name: "Mark", city: "London"})
CREATE (jennifer:Engineer {name: "Jennifer", city: "St Louis"})
CREATE (michael:Engineer {name: "Michael", city: "Dresden"})
CREATE (jim:Engineer {name: "Jim", city: "London"})
CREATE (alistair:Engineer {name: "Alistair", city: "London"})

MERGE (jim)-[:COLLEAGUES {since: date("2006-05-01")}]->(alistair)
MERGE (mark)-[:COLLEAGUES {since: date("2018-02-01")}]->(jennifer)
MERGE (mark)-[:COLLEAGUES {since: date("2013-05-01")}]->(michael)

If we execute this query, it will result in the following graph:

Renaming node labels

The following changes the label on Mark, Jennifer, and Michael from Engineer to DevRel:

MATCH (person:Engineer)
WHERE person.name IN ["Mark", "Jennifer", "Michael"]
WITH collect(person) AS people
CALL apoc.refactor.rename.label("Engineer", "DevRel", people)
YIELD committedOperations
RETURN committedOperations

If we execute this query, it will result in the following graph:

Renaming relationship types

The following changes the relationship type between Jim and Alistair from COLLEAGUES to FROLLEAGUES:

MATCH (:Engineer {name: "Jim"})-[rel]->(:Engineer {name: "Alistair"})
WITH collect(rel) AS rels
CALL apoc.refactor.rename.type("COLLEAGUES", "FROLLEAGUES", rels)
YIELD committedOperations
RETURN committedOperations

Renaming node properties

The following query changes the node property city to location for all nodes with the DevRel label:

MATCH (person:DevRel)
WITH collect(person) AS people
CALL apoc.refactor.rename.nodeProperty("city", "location", people)
YIELD committedOperations
RETURN committedOperations

The following query returns all the nodes in our graph after this refactoring has been done:

MATCH (n)
RETURN (n)

Table 2. Results
n
(:DevRel {name: "Jennifer", location: "St Louis"})
(:DevRel {name: "Michael", location: "Dresden"})
(:Engineer {city: "London", name: "Jim"})
(:DevRel {name: "Mark", location: "London"})
(:Engineer {city: "London", name: "Alistair"})

Renaming relationship properties

The following query changes the relationship property since to from for all relationships:

MATCH ()-[rel]->()
WITH collect(rel) AS rels
CALL apoc.refactor.rename.typeProperty("since", "from", rels)
YIELD committedOperations
RETURN committedOperations

The following query returns all the paths in our graph after this refactoring has been done:

MATCH path = ()-[]->()
RETURN path

Table 3. Results
path
[{"name":"Mark","location":"London"},{"from":"2018-02-01"},{"name":"Jennifer","location":"St Louis"}]
[{"name":"Mark","location":"London"},{"from":"2013-05-01"},{"name":"Michael","location":"Dresden"}]
[{"name":"Jim","city":"London"},{"from":"2006-05-01"},{"name":"Alistair","city":"London"}]