With current version, 2.2.14:

• Neo4j Nodes with same Label but different case, e.g. LABEL and LAbel will be aggregated into a single OrientDB vertex Class
• Neo4j Relationship with same name but different case, e.g. relaTIONship and RELATIONSHIP will be aggregated into a single OrientDB edge Class

This is an enhancement request to allow users to customize the strategy. The above can be one strategy, but other strategies are possible, e.g. append a random string to the label or relationship type, and migrate them into separated classes

This seems to be not a common case - but could be useful to improve how we behave here anyway

Improve automated test suite by adding more databases:

• movie
• northwind
• reactome
• panama papers

and

• more asserts

By design, nodes with multiple labels should be recognized, and only the first label used during the import into OrientDB

However, due to a bug, number of nodes with multiple labels is not written in the migration summary, and instead of the first label the last one is used during the migration

Hash provides fast lookup and is very light on disk usage. Should be perfect for some properties that the importer uses internally

That can be used, after the migration, to compare original and migrated databases

In particular, it would be useful to have:

• list of neo4j labels
• list of neo4j constraints and indexes

compared to:

• list of orientdb classes
• lis of orientdb contraints and indexes

Right now only the first label is migrated and info on the other labels is loss

List of labels can be stored in an additional vertex property of type EMBEDDEDLIST STRING. This property can be indexed (this will allow fast queries "by labels")

Even if the multi-label nodes are migrated into a single class, it will then be possible to filter nodes that had a specific label, e.g.

select * from V where Neo4jLabelList IN ['NodeLabelB']

and equivalent match, e.g.

MATCH {class: V, as: NodeLabelB, where: (Neo4jLabelList IN ['NodeLabelB']) } RETURN NodeLabelB.Neo4jNodeID, NodeLabelB.other_property, NodeLabelB.Neo4jLabelList

A violation against the OSS Rules of Play has been detected.

Rule ID: rl-reuse_tool-1
Explanation: Does README mention REUSE? No

Find more information at: https://sap.github.io/fosstars-rating-core/oss_rules_of_play_rating.html

On certain conditions, too much info is written in the migration log

As a consequence migration is slowed down and log becomes unreadable

One case is when a neo4j's relationship type with the same name of a neo4j's label is found. In this case a message similar to the following is written:

WARNING: Found a Neo4j Relationship ('summation') with same name of a Neo4j node Label ('Summation'). Importing this relationship in OrientDB as 'E_summation

However this message is written for every relationship that has the same type of a node label. As a consequence, if there are many such relationships lot of similar messages will be written in the log, and this will impact migration performance

A possible fix is to write the message only for the first found relationship type (and not for all found relationships of that type)

Easily reproducible with reactome.graphdb

A violation against the OSS Rules of Play has been detected.

Rule ID: rl-reuse_tool-4
Explanation: Is it compliant with REUSE rules? No

Find more information at: https://sap.github.io/fosstars-rating-core/oss_rules_of_play_rating.html

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.

A violation against the OSS Rules of Play has been detected.

Rule ID: rl-vulnerability_alerts-1
Explanation: Are vulnerability alerts enabled? No

Find more information at: https://sap.github.io/fosstars-rating-core/oss_rules_of_play_rating.html

Sometime the test shouldImportMultipleLabelsAndConstraintsDb fails

As workaround and to speed up record lookup, as in certain cases (e.g. nodes of different labels aggregated into a single class in OrientDB) it is expected that the unique index creation fails (as there are "null" values for that property for those nodes that in *eo4j had different label and now are in a single class)

This will improve how migrated relationships can be queried by original Neo4j relationship ID

Possible Workaround:

• using Studio or the Console, on the E (edge) class, create a property named Neo4jRelID and then a unique index on this property. This will allow you to query relationship by neo4j id using a query like:

select * from E where Neo4jRelID = your_id_here

A violation against the OSS Rules of Play has been detected.

Rule ID: rl-license_file-2
Explanation: Does it use an allowed license? No

Find more information at: https://sap.github.io/fosstars-rating-core/oss_rules_of_play_rating.html

I'd like to suggest something...
an import prefs configuration file that defines

the DB name for the import
the names of the Neo4Jid and Neo4jLabels properties to import to
whether or not to overwrite or append to (possible) existing database

IHMO, I would like to use a particular DB rather than neo4j_import ( otherwise I have to rename it when I'm done importing )
I would like the ID and labels to be something I use going forward rather than renaming those properties or copying those properties to something else
I would like to import into an existing DB so I don't have to repeat the process over and over.

...maybe there are other configuration items possible

Examples

Vertex Type

- OrientVertexType writer = graph.createVertexType("Writer");
+ OClass writer = schema.createClass("Writer", v);

EdgeType

- graph.createEdgeType("Writes");
+ schema.createClass("Writes", e);

AddEdge

-    db.addEdge("class:Writes", writer, post, null);
+    db.newEdge(writer, post, "Writes");

AddVertex

-    OrientVertex post = db.addVertex("class:Post");
+    OVertex post = db.newVertex("Post");

Dep

-import com.tinkerpop.blueprints.impls.orient.OrientBaseGraph;
-import com.tinkerpop.blueprints.impls.orient.OrientGraphNoTx;
-import com.tinkerpop.blueprints.impls.orient.OrientVertex;
-import com.tinkerpop.blueprints.impls.orient.OrientVertexType;

+import com.orientechnologies.orient.core.record.OVertex;
+import com.orientechnologies.orient.core.db.ODatabase;

Pom

- <artifactId>orientdb-graphdb</artifactId>
+<artifactId>orientdb-server</artifactId>

Avoid progresses are written every time one vertex or edge has been created, but rather update progress % every say 1 second

This should improve performance

A violation against the OSS Rules of Play has been detected.

Rule ID: rl-reuse_tool-2
Explanation: Does it have LICENSES directory with licenses? No

Find more information at: https://sap.github.io/fosstars-rating-core/oss_rules_of_play_rating.html

From 4g to 512g (it does not mean that 512g will be allocated, but it can avoid OOM)

A violation against the OSS Rules of Play has been detected.

Rule ID: rl-reuse_tool-3
Explanation: Is it registered in REUSE? No

Find more information at: https://sap.github.io/fosstars-rating-core/oss_rules_of_play_rating.html

Right now we have it at the end of the import process, as "average" speed

Would be good to have also a "point" or instantaneous speed. This would allow to see if this speed is changing / degrading over time