Фильтрация пути с множественными отношениями переменной длины (запрос людей, которых вы знаете) - PullRequest
Новая
       32

Фильтрация пути с множественными отношениями переменной длины (запрос людей, которых вы знаете)

0 голосов
/ 04 июля 2019

Допустим, у нас есть User узлы, Company узлы, Project узлы, School узлы и Event узлы. И есть следующие отношения между этими узлами

  • (User)-[:WORKED_AT {start: timestamp, end:timestamp}]->(Company)
  • (User)-[:COLLABORATED_ON]->(Project)
  • (Company)-[:COLLABORATED_ON]->(Project)
  • (User)-[:IS_ATTENDING]->(Event)
  • (User)-[:STUDIED_AT]->(School)

Я пытаюсь рекомендовать пользователей любому пользователю. Мой стартовый запрос выглядит так 

MATCH p=(u:User {id: {leftId}})-[r:COLLABORATED_ON|:AUTHORED|:WORKED_AT|:IS_ATTENDING|:STUDIED_AT*1..3]-(pymk:User)
RETURN p
LIMIT 24

Теперь это возвращает мне всех pymk пользователей в пределах от 1 до 3 отношений, и это нормально. Но я хочу отфильтровать путь по атрибутам отношений. Например, удалите следующий путь, если даты начала и окончания работы user и pymk не перекрываются.

(User)-[:WORKED_AT]->(Company)<-[:WORKED_AT]-(User)

Я могу сделать это одним запросом 

MATCH (u:User)-[r1:WORKED_AT]->(Company)<-[r2:WORKED_AT]-(pymk:User)
WHERE 
    (r1.startedAt <  r2.endedAt) AND (r2.startedAt < r1.endedAt)
RETURN pymk

Но я не мог заставить себя делать это в совокупности путей. Я даже не знаю, возможно ли это.

Любая помощь приветствуется.

1 Ответ

0 голосов
/ 06 июля 2019

Это должно сработать: 

MATCH p=(:User {id: {leftId}})-[:COLLABORATED_ON|:AUTHORED|:WORKED_AT|:IS_ATTENDING|:STUDIED_AT*1..3]-(:User)
WITH p, [rel in relationships(p) WHERE type(rel) = 'WORKED_AT'] as worked
WHERE size(worked) <> 2 OR 
  apoc.coll.max([work in worked | work.startedAt]) < apoc.coll.min([work in worked | work.endedAt])
RETURN p
LIMIT 24

Мы используем APOC здесь, чтобы получить максимум и минимум коллекции (функции агрегации max() и min() только в Cypher являются функциями агрегациимежду строками и не может использоваться в списках).

Это основано на использовании логики перекрытия до max([start times]) < min([end times]), которую вы можете проверить в этом очень популярном ответе здесь

...