Open rulatir opened 8 years ago
It is only added if you have no constraints on your nodes, if you have constraints on a label + properties, those are used instead. Can you share your example graph + export file?
The values of the UNIQUE IMPORT ID
property are used in the part that attempts to create relationships:
MATCH (n1:`UNIQUE IMPORT LABEL`{`UNIQUE IMPORT ID`:23}), (n2:`UNIQUE IMPORT LABEL`{`UNIQUE IMPORT ID`:469}) CREATE (n1)-[:`TAG` {`created_at`:"2015-12-10 10:35:48", `updated_at`:"2015-12-10 10:35:48"}]->(n2);
even though they have not been set in the part that creates nodes:
CREATE (:`AppJointTagSearch`:`UNIQUE IMPORT LABEL` {`created_at`:"2015-12-10 06:23:33", `updated_at`:"2015-12-10 06:23:33", `value`:"435"});
This cannot possibly be correct, and the result is that no relations are created at all because no nodes match in the statements that are supposed to create relations.
Can you share an example graph where that happens?
Sure. Create:
CREATE (n1:Foo)-[:CHILD]->(n2:Bar)
Export command:
export-cypher -o export.cypher -r
export.cypher:
begin
CREATE (:`Foo`:`UNIQUE IMPORT LABEL`);
CREATE (:`Bar`:`UNIQUE IMPORT LABEL`);
commit
begin
CREATE CONSTRAINT ON (node:`UNIQUE IMPORT LABEL`) ASSERT node.`UNIQUE IMPORT ID` IS UNIQUE;
commit
schema await
begin
MATCH (n1:`UNIQUE IMPORT LABEL`{`UNIQUE IMPORT ID`:7266}), (n2:`UNIQUE IMPORT LABEL`{`UNIQUE IMPORT ID`:7267}) CREATE (n1)-[:`CHILD`]->(n2);
commit
begin
MATCH (n:`UNIQUE IMPORT LABEL`) WITH n LIMIT 1000 REMOVE n:`UNIQUE IMPORT LABEL` REMOVE n.`UNIQUE IMPORT ID`;
commit
begin
DROP CONSTRAINT ON (node:`UNIQUE IMPORT LABEL`) ASSERT node.`UNIQUE IMPORT ID` IS UNIQUE;
commit
Ow, this is a bad bug, it can cause data loss.
It is only added if you have no constraints on your nodes, if you have constraints on a label + properties, those are used instead.
You must always add it! Because even if there is a constraint
CREATE CONSTRAINT ON (node:`Label`) ASSERT node.`attribute` IS UNIQUE;
that does not mean
node.`attribute`
exists for every
(node:`Label`)
In that case, the export just stops at the first node without attribute
, creating an invalid Cypher file.
Please warn users not to use the Cypher export functionality without understanding the issues described in this bug, as long as this bug is not fixed.
Good point, thanks for raising it. I'll add a fix.
Running into this as well. Is there a fix for this already?
I fixed it apoc but will fix it here too
Von meinem iPhone gesendet
Am 26.08.2016 um 01:49 schrieb Josemar Luedke notifications@github.com:
Running into this as well. Is there a fix for this already?
— You are receiving this because you commented. Reply to this email directly, view it on GitHub, or mute the thread.
I fixed it apoc but will fix it here too
To be clear: this means that for the 3.0 version, this is fixed, right?
I've run into this problem as well. I tested it with neo4j-shell-tools_3.0.1
, 3.0.3
, and 3.1.0
, but it didn't seem to be fixed yet. I finally used APOC with cypher-shell, which did the job very well.
I just exported the database, and it seems that the
UNIQUE IMPORT ID
properties are not written at all in the cypher file. They are matched against in the section that creates relations, but they are not set in the earlier section that creates nodes. The first occurence ofUNIQUE IMPORT ID
is in the CREATE CONSTRAINT statement.I am using neo4j-shell-tools 2.2 because I am exporting from a neo4j-2.2 server instance. Should I be using the newest tools? Are they backward compatible with 2.2?