Cypher: проблема с заменой! оператор недвижимости

Question

Я только что видел (здесь: http://docs.neo4j.org/chunked/1.9/deprecations.html), что! оператор для выражений свойства Cypher будет устаревшим с выпуском Neo4j 2.0. Поэтому я пошел переформулировать мои существующие запросы Cypher и столкнулся с следующей проблемой.

1,9 запрос: START n=node(*) WHERE NOT "NO_FACET" in n.uniqueLabels! RETURN n limit 2;

Что я получаю: Узлы, которые либо не имеют свойство «uniqueLabels» на все или узлах, которые обладают этим свойством, но не содержат значение «NO_FACET».

Приведенная выше ссылка говорит об обходе таких выражений, делая отметку has(n.uniqueLabels" AND NOT "NO_FACET" IN n.uniqueLabels. Этот запрос работает, но это, очевидно, не то, что я хотел (я также хотел, чтобы узлы вернулись, у которых вообще нет свойства). Предлагаемое обход выглядит как ленивый И-оценка, которая будет хорошо для меня. Так что я сделал это:

START n=node(*) WHERE NOT (has(n.uniqueLabels) AND "NO_FACET" in n.uniqueLabels) RETURN n limit 2;

Но здесь я получаю сообщение об ошибке: ==> EntityNotFoundException: The property 'uniqueLabels' does not exist on Node[0] Так оценка не настолько ленивы, в конце концов? Странная вещь, этот запрос работает:

START n=node(*) WHERE has(n.uniqueLabels) AND "NO_FACET" in n.uniqueLabels RETURN n limit 2;

Он просто дает мне прямо противоположное тому, что я хотел, конечно.

На самом деле я могу получить то, что я хочу без оператора, как это:

START n=node(*) WHERE NOT has(n.uniqueLabels) OR (has(n.uniqueLabels) AND NOT "NO_FACET" in n.uniqueLabels) RETURN n limit 2;

Но я не уверен, если это то, как он был предназначен, когда оператор был устаревшим. Таким образом, вопрос заключается в том, упускаю ли я правильный путь для этого или если поведение И в сочетании с НЕ вне круглых скобок является ошибкой, возможно?

И кстати: Кто-нибудь теперь, почему! во-первых, оператор устарел? Мне нравится ;-)

Благодарим за понимание и с наилучшими пожеланиями!

Answer 1

Я считаю, что это может быть вызвано тем, как NOT оценивает выражение внутри него. Это может быть не короткое замыкание выражения AND, которое может привести к тому, что он не будет оценивать второе выражение.

Одно из решений: De Morgan's Law (Busting out CS 101). Вы запрос превратитесь в это:

START n=node(*) 
WHERE NOT(has(n.uniqueLabels)) OR NOT("NO_FACET" in n.uniqueLabels)) 
RETURN n limit 2; 

Я не 100% уверен, почему осуждается этот оператор, он может иметь дело с делая Cypher ключевых слов языка в соответствии с чем-то вроде SQL, но ситуация кажется больше похоже на ошибку в их системе, так как выражение должно замыкаться на И в инструкции NOT.