Improve migration in case of Neo4j nodes with multiple labels: allow customized mapping between label and classes

[santo-it]

Version 2.2.14 improved a bit how the migration is done in case the original Neo4j nodes have multiple labels

But there's an important additional step do support and release to improve user's experience: allow a customized mapping between Neo4j labels and OrientDB classes

Let's suppose there are N labels in Neo4j. User should be able, using a configuration file, to decide how these N labels are migrated. A few cases:

A. Single label nodes

N labels -migrated-to-the-corresponding-> N classes (happens already today)

N labels -migrated-to-> M classes , where M<>N. Users decide their own mapping, e.g.

N1 label --> M1 class
N2 label --> M2 class
N3 & N4 labels --> M3 class
N5 label --> M4 class
etc

A. Multiple label nodes

Customized mapping is important in particular in case of neo4j nodes with multiple labels:

N1 & N2 labels --> M1 class
N3 & N4 labels --> M2 class
N5 & N6 labels --> M3 class
etc

Customized mapping details

The customization can be done using a configuration file, that the import will read at run-time.

In the first stage the user is expected to edit the configuration file manually.

In the second stage, after the integration between the importer and the Studio tool has been done, the user should be able to do such mapping visually, in a similar way on how visual mapping happens with the tool teleporter.

Note that during the visual mapping process a configuration file is created (in a transparent way for the user), and the importer will then read it and no additional modification to the import code will be needed (in other words, in this second stage only the way the configuration file is created changes: it can be created either manually or visually, but the code in the import remains the same)

Implementation details

From a technical point of view, to allow customized mapping between labels and classes only the part related to nodes migration has to be changed. Relationships and schema migration is not affected

In particular, only the part where the vertex class (to be used) is determined has to be changed. To keep code clean and clear, a function that returns the class name can be used, and all the logic (read the configuration file and determine the class) can be put into this function.

[santo-it]

Ping @lvca FYI and ping @G4br13l3 for technical requirements, guidelines and/or examples on how this configuration file has to be created. Thanks