Предложение MATCH
, которое не соответствует, отменяет остальную часть запроса (и запрос ничего не возвращает).
Следующий фрагмент никогда не будет ничего совпадать, так как он пытается соответствовать user
узлы, имеющие связанный skill
узел, чье значение Id
соответствует несуществующему значению (что не имеет смысла):
MATCH (user)-[:HAS_SKILL]->(skill: Skill)
WHERE skill.Id IN []
Чтобы создать отношение USED_SKILL
, только если user
не имеетумение, сделайте следующее:
MATCH (user: User)
WHERE user.Id = "74994fd8-40bb-48e8-adf1-bc11eeb6c035"
MERGE (project: Project {Id: '02d5ad72-036c-47e9-a366-d5ca4a3e66e2'})
ON CREATE
SET project += {
Name: "VINCI GTR",
Description: "Description of VINCI GTR",
StartedTime: 0.0
}
MERGE (user)-[:DID_PROJECT]->(project)
WITH project, user
WHERE SIZE((user)-[:HAS_SKILL]->()) = 0
MERGE (project)-[:USED_SKILL]->(skill)
RETURN project
Этот запрос выполняет проверку степени на каждом узле user
, чтобы найти те, которые не имеют отношений HAS_SKILL
(мы намеренно опускаем метку :Skill
впротивоположный узел в шаблоне, который является своего рода хаком, заставляющим планировщик Cypher генерировать более эффективную операцию).Кроме того, мы используем SET +=
вместо SET =
, чтобы не заменять все свойства узла, что позволяет избежать необходимости перезаписывать значение Id
тем же значением.
Кстати:
Соотношение HAS_SKILL_CATEGORY
представляется избыточным.Если все навыки пользователя могут быть достигнуты через HAS_SKILL
отношения, то вы уже можете получить категории этого пользователя через что-то вроде этого:
MATCH (user: User)-[:HAS_SKILL]->()-[:BE_IN_SKILL_CATEGORY]->(c)
WHERE user.Id = "74994fd8-40bb-48e8-adf1-bc11eeb6c035"
RETURN c;