Neo4j密码查询生成器

我一直在尝试为Neo4j的查询语言Cypher设计一个查询生成器，理想的情况是使用流畅的API。我没找到多少，决定自己花点时间建造一个

到目前为止，结果是针对Cypher 1.9规范的fluent API查询生成器

在我发布代码之前，我想用StackOverflow开始一场讨论，看看想法是什么

下面是一个演示查询，您希望使用Cypher发送给Neo4j

让我看看John认识的所有人，谁认识谷歌的软件工程师（谷歌公司代码假定为12345）。 约翰和那些把他和谷歌员工联系起来的人之间的关系强度至少应该是3（假设范围是1-5）。 返回John的所有联系和他们在Google认识的人，包括这些人之间的关系。 将结果按John的连接名称按升序排序，然后按关系强度按降序排序

使用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

---

我喜欢您的第一个示例，其中您仅使用文本来描述查询。第二种选择，告诉你真相，在我看来并不比构建密码查询本身容易多少。该语言非常容易使用，并且有很好的文档记录。添加另一层抽象只会增加复杂性。但是，如果您找到一种将此自然语言请求转换为密码请求的方法，那就太酷了：）

另外，为什么不直接开始使用Cypher 2.0呢

最后，在这里检查一下：–我正在处理一个类似的问题，但是要将节点添加到数据库中，而不是查询它们。我选择使用#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的一个更好、更有用的简化。

我同意你应该着眼于Cypher 2.0来构建它。从2.0开始，非常重要的是，

其中

子句与正确的

开始

，

（可选）匹配

，

和

子句使得流畅API的设计更具挑战性。

这里的问题是什么？这更像是一个开放式的问题，旨在接收关于流畅cypher API的反馈和建议。你看到（对于java）我喜欢你的DSL了吗？把它放在github/maven/npm上并写博客怎么样？这将是收集反馈的最佳方式。Neo4j谷歌小组可能也更适合此类讨论。dsl是否与最新版本的Neo4JHey deemeetree兼容谢谢您的回复。我同意，Cypher已经很容易理解了。Fluent API的实际好处更多地在于它读起来像文本，并且很容易理解我们要做的事情，但更重要的是，API只允许您将定义良好的格式组合在一起，从而生成语法正确的查询。摆弄字符串操作来组合密码查询非常容易出错，没有人知道字符串中的内容是否正确。在这里，如果你做错了什么，编译器会抱怨。