2014-02-16 3 views
7

Я пытаюсь найти конструктор запросов для языка запросов Neo4j Cypher, в идеале используя свободный API. Я многого не нашел и решил потратить некоторое время на создание одного.Neo4j Cypher Query Builder

Результат до сих пор является плавным построителем запросов API для спецификации Cypher 1.9.

Я хотел использовать StackOverflow, чтобы начать обсуждение и посмотреть, что представляют собой мысли, прежде чем я выпущу код.

Это демонстрационный запрос, который вы хотите отправить в Neo4j с помощью Cypher.

Показать все люди, которые знают Джон, кто знает инженеров-программистов в Google (код компании Google считается 12345). Сила отношений между Джоном и людьми, которые связывают его с сотрудниками Google, должна составлять не менее 3 (при диапазоне от 1 до 5). Верните все связи Джона и людей, которых они знают в Google, включая отношения между этими людьми. Сортируйте результаты по именам соединений Джона в порядке возрастания, а затем по силе отношения в порядке убывания.

Использование Fluent-Cypher:

Cypher 
    .on(Node.named("john").with(Index.named("PERSON_NAMES").match(Key.named("name").is("John")))) 
    .on(Node.named("google").with(Id.is(12345))) 

    .match(Connection.named("rel1").andType("KNOWS").between("john").and("middle")) 
    .match(Connection.named("rel2").andType("KNOWS").between("middle").and("googleEmployee")) 
    .match(Connection.withType("WORKS_AT").from("googleEmployee").to("google")) 

    .where(Are.allOfTheseTrue(Column.named("rel1.STRENGTH").isGreaterThanOrEqualTo(3) 
      .and(Column.named("googleEmployee.TITLE").isEqualTo("Software Engineer")))) 

    .returns(Columns.named("rel1", "middle", "rel2", "googleEmployee")) 
    .orderBy(Asc.column("middle.NAME"), Desc.column("rel1.STRENGTH")) 

, который дает следующий запрос:

START john=node:PERSON_NAMES(name='John'),google=node(12345) MATCH john-[rel1:KNOWS]-middle,middle-[rel2:KNOWS]-googleEmployee,googleEmployee-[:WORKS_AT]->google WHERE ((rel1.STRENGTH >= '3' AND googleEmployee.TITLE = 'Software Engineer')) RETURN rel1,middle,rel2,googleEmployee ORDER BY middle.NAME ASC,rel1.STRENGTH DESC 
+0

В чем вопрос? –

+0

Это скорее открытый вопрос, предназначенный для получения отзывов и предложений по свободному API-интерфейсу cypher. – sebastij

+0

Вы видели (для java) https: // github.com/neo4j/cypher-dsl –

ответ

0

мне нравится ваш первый пример, где вы просто использовать текст для описания запроса. Второй вариант, чтобы сказать вам правду, выглядит мне не намного проще, чем сам запрос Cypher. Язык довольно прост в использовании и хорошо документирован. Добавление другого уровня абстракции только увеличило бы сложность. Однако, если вы найдете способ перевода этого запроса на естественный язык в запрос Cypher, это было бы здорово :)

Кроме того, почему бы не начать работать непосредственно с Cypher 2.0?

Наконец, проверьте это здесь: http://github.com/noduslabs/infranodus - Я работаю над аналогичной проблемой, но для добавления узлов в базу данных, а не для их запроса. Я решил использовать #hashtags, чтобы люди могли понять, как их запросы должны быть структурированы (как мы их уже используем). Так что в вашем случае это может стать чем-то вроде

@show-all #people who #John :knows who :know #software-engineers :at #Google. 

@relationship-strength between #John and the #people who are @linked to #Google #software-engineers should be at least @3 

@return @all of #John's @connections and the #people they :know at #Google, including the @relationships-between those #people. 

@sort the @results @by-name of #John's @connections in @ascending order and then by @relationship-strength in @descending order. 

(скажем, #hashtags относятся к узлам, то @at относится к действиям на них)

Если бы вы могли вытащить что-то вроде этого прочь, я думаю, это было бы намного лучше и полезнее упростить уже простой в использовании Cypher.

+1

Hey deemeetree Спасибо за ваш ответ. Согласен, Cypher уже достаточно легко понять. Фактическое преимущество Fluent API заключается в том, что он читается как текст, и легко понять, что мы пытаемся сделать, но что более важно, API только позволяет вам собрать четко определенные форматы, которые дают синтаксически правильную запрос. Скручивание с помощью операций со строками, чтобы собрать запрос Cypher, довольно восприимчиво к ошибкам, и никто не знает, правильно ли указано в Строке. Здесь компилятор будет жаловаться, если вы сделали что-то неправильно. – sebastij

1

Я согласен, что вы должны построить это с глазом по направлению к Cypher 2.0. По состоянию на 2.0 очень важно, чтобы статьи WHERE были согласованы с правильными START, (OPTIONAL) MATCH и WITH предложениями, делающими дизайн свободного API немного более сложным.

Смежные вопросы