Странное поведение, наблюдаемое в вашем примере, может показаться ошибкой, но его можно объяснить (после некоторого тщательного обдумывания).После всего сказанного и сделанного один вывод заключается в том, что следует избегать использования несвязанных узлов в предложении MERGE
.
Нечетное поведение
Ваш запрос на создание имеетНет MERGE
предложение для создания itemz
узла i5
.То есть этот пункт отсутствует: MERGE (i5:itemz {id: 5})
.
Поэтому может показаться, что предложения 2 MERGE (a4)-[:AUTHOR]->(i5)
должны привести к созданию нового немеченого узла i5
снет свойств - но такой узел не создается!
И может показаться, что предложение MERGE (a5)-[:AUTHOR]->(i5)
должно привести к связи с этим новым i5
- но вместо этогонеожиданно приводит к отношениям с i4
!
Объяснение
Этот фрагмент кода вызывает странное поведение (я добавил комментарии, чтобы уточнить):
MERGE (a4)-[:AUTHOR]->(i4) // Makes sure `(a4)-[:AUTHOR]->(i4)` relationship exists
MERGE (a4)-[:AUTHOR]->(i5) // Matches above relationship, so creates `i5` and binds it to `i4`!
MERGE (a4)-[:AUTHOR]->(i5) // Matches same relationship, so nothing is done.
Итак, после выполнения фрагмента i4
и i5
связаны с одним и тем же узлом.Это объясняет странное поведение.
Заключение
Чтобы избежать неожиданных результатов, следует избегать использования несвязанных узлов в предложениях MERGE
.
Если ваш запрос на создание имел включал предложение MERGE (i5:itemz {id: 5})
до того, как были созданы отношения, тогда ваши запросы работали бы разумно.Результат первого запроса будет содержать accz
узлов 3 и 4, а результат второго запроса будет содержать только 3.
Кстати, ({id: i.id} IN [({id: 3}), ({id: 4})])
можно значительно упростить доi.id IN [3, 4]
.