Это иллюстрирует, почему рекомендуется обрабатывать отдельные CSV-файлы для каждого типа узла, поэтому вы всегда сможете узнать, какую метку жестко закодировать в запросе.
Это требование для Cypher, потому что когда меткижестко закодированы, планировщик использует метаданные в БД, чтобы помочь в том, как эффективно планировать выполнение запроса (оценка динамических меток должна произойти во время выполнения ... это бесполезно для планировщика, который должен планировать запрос до выполнения).
В этом случае лучше всего добавить вторую, более общую метку для всех узлов каждого из добавленных типов, а затем создать индексиспользуя свойство key
и эту общую метку, и используйте эту общую метку для поиска при создании отношений.
Итак, после применения общей метки (давайте просто назовем ее: Node for now) и индексасоздан на: Узел (ключ), это так же просто, как:
USING PERIODIC COMMIT 500 LOAD CSV WITH HEADERS FROM 'file:///IDES__Edges1.csv' AS line
MATCH (x:Node {key:line.SOURCE_KEY}), (y:Node {key:line.TARGET_KEY})
CALL apoc.create.relationship(x, line.LABEL, y) YIELD rel
RETURN count(*)
Это предполагает, конечно, что ключи являются уникальными среди всехУзлы со всеми заданными метками.Если это не так, тогда потребуется другой подход.