在此期间运行一些其他查询后重复查询可能会导致不同的结果。这只出现在较大的数据库中,并且重现起来有点困难。但是,以下协议几乎肯定(在Windows和Linux安装上工作)显示同样的问题:
从CSV加载许多节点。
//load nodes from UTF-8 encoded TSV file
USING PERIODIC COMMIT
LOAD CSV WITH HEADERS FROM 'file:///all_nodes.tsv' AS row FIELDTERMINATOR ' '
MERGE (root:UID {Spec:row.UID})
WITH root,row
// set additional label
CALL apoc.create.addLabels(root,[row.Label]) YIELD node AS labnode
// set additional property
CALL apoc.create.setProperty(root,row.PropName,row.PropValue) YIELD node as propnode
RETURN count(*)
从CSV加载许多关系。
// load relationships from UTF-8 encoded TSV file
USING PERIODIC COMMIT
LOAD CSV WITH HEADERS FROM 'file:///all_edges.tsv' AS row FIELDTERMINATOR ' '
MATCH (sourcenode:UID {Spec:row.SourceUID})
MATCH (targetnode:UID {Spec:row.TargetUID})
WITH row,sourcenode,targetnode
CALL apoc.merge.relationship(sourcenode,row.Relationship,CASE row.PropName
WHEN "Source" THEN {Source:row.PropValue} ELSE {} END,{}, targetnode) YIELD rel
RETURN count(*)
7.5。 MATCH(n)返回计数(*)。
7.6。 MATCH() - [r] - >()返回计数(*)。
8.5。 MATCH(n)返回计数(*)。
我无法公开我的数据,所以我只能显示数字:
测试案例1: 已加载5908886个节点和11801553个关系。 小批量删除所有关系。 最后用MATCH() - [r] - >()删除r。 数据库包含5908886个节点和0个关系。 已加载11801871关系。 数据库包含5908886个节点和11801871个关系。
测试案例2: 已加载3338901个节点和8892829个关系。 小批量删除所有关系。 最后用MATCH() - [r] - >()删除r。 数据库包含3338901个节点和0个关系。 已加载8893041的关系。 数据库包含3338901个节点和8893041个关系。
差异只有318和212关系,但它们不应该是0?
编辑:已找到部分解决方案。上述两个测试用例包含未导入的Neo4j控制字符,例如要导入的属性值中的/(正斜杠)。 APOC没有将这些识别为错误,因此将它们引入数据库存储。每当运行访问这些参数值的查询时,它都会导致意外的副作用,这些副作用会被破坏。数据库。通过从CSV输入中删除这些错误的属性值,或多或少地解决了该问题。