Neo4j Traversal Framework Expander и заказ

Я пытаюсь понять API обхода Java Neo4J, но после тщательного чтения я застрял в некоторых моментах.

Что я, кажется, знаю:

Разница между PathExpander и BranchOrderingPolicy. Насколько я понимаю, первая говорит о том, какие отношения могут быть исследованы с определенной позиции, а вторая указывает порядок, в котором они должны оцениваться.

Я хотел бы знать следующее:

  1. Правильно ли это понимание и в какой степени, или можно ли его изменить, чтобы дать правильное понимание.

  2. Если верно, то чем PathExpander отличается от Evaluator.

  3. Как работают PathExpander и BranchOrderingPolicy. Я хочу спросить, PathExpander консультируются каждый раз, когда отношение добавляется к обходу, и что он делает с итерацией возвращаемых отношений. Аналогично с порядком веток.

  4. Во время обхода, как и когда появляются компоненты Expander, BranchOrdering, Evaluator, Uniqueness. В основном я хочу знать алгоритм шаблона, где можно сказать, что первый расширитель запрашивает набор отношений для расширения, а затем проверяется политика заказа, чтобы выбрать один из подходящих ....

  5. Если верно, применяется ли политика заказа, указанная в BranchOrderingPolicy, только к приемлемым отношениям (после того, как расширитель сделал это). Возможно, так и должно быть.

Пожалуйста, включите что-нибудь еще, что может быть полезно для понимания API.


neo4j graph-databases graph-traversal
person mickeymoon    schedule 08.01.2014    source источник

Ответы (1)


arrow_upward
6
arrow_downward

Я постараюсь описать эти части как можно лучше.

  1. Что касается разницы между PathExpander и BranchOrderingPolicy: PathExpander вызывается для каждой ветви обхода в первый раз, когда обход продолжается с этой ветки. (Переходная ветвь - это узел, включающий путь, ведущий к этому узлу, обратите внимание, что может быть много путей, то есть много ветвей к одному и тому же узлу, в основном в зависимости от уникальности). Результатом вызова PathExpander является Iterator<Relationship>, который будет лениво предоставлять новые отношения из этой ветви обхода, когда это необходимо. Это подводит нас к BranchOrderingPolicy, который рассматривает все живые ветви обхода. Под «живым» я подразумеваю ветвь, в которой есть одно или несколько отношений, так что из нее можно создать больше ветвей. Учитывая все живые ветки, он выбирает одну из них, следуя своей следующей взаимосвязи (полученной из итератора отношений в этой ветке, возможно, если это первый вызов, инициализирует этот итератор с помощью PathExpander (как описано выше).
  2. Разница между PathExpander и Evaluator: это разделение во многом связано с удобством и разделением интересов. PathExpander увеличивает количество ветвей и Evaluator фильтров, т.е. уменьшает количество ветвей. Расширитель создает новые ветви, которые оцениваются Evaluator. С учетом сказанного вы можете написать PathExpander, который выполняет обе эти функции, и это могло бы быть более эффективным. Но удобство их разделения, когда может быть несколько Evaluator, весьма полезно.
  3. См. Выше (1)
  4. Некоторые из них описаны в (1), но более широкая картина будет заключаться в том, что BranchOrderingPolicy является драйвером в обходе - из каждой живой ветки он выбирает одну и следует за ней одно отношение к новой ветке. Будут созданы только ветки, соответствующие выбранной уникальности. Отношения для ветви извлекаются в первый раз, когда это происходит для каждой ветви, в форме ленивого итератора отношений с использованием PathExpander. Новые ветки оцениваются при первом выборе, когда один результат оценки заключается в том, является ли эта ветвь тупиком, а другой - включать ли ее в результат, передаваемый пользователю.
  5. Я думаю, что вышесказанное объясняет, что

Достаточно ли этой информации?

person Mattias Finné    schedule 10.01.2014
comment
спасибо @Mattias ... Думаю, этого было достаточно для меня, чтобы проанализировать собственное понимание. - person mickeymoon; 22.01.2014