Hi guys, I am in the process of creating a Java DSL for Cypher, and would like your feedback on different variants. You can find the code here: https://github.com/neo4j/cypher-dsl/
The Cypher reference manual has been implemented here: https://github.com/neo4j/cypher-dsl/blob/master/src/test/java/org/neo4j/cypherdsl/CypherReferenceTest.java That should provide reasonable amount of examples of usage. There are a couple of variants of implementation that I'd like your views on. The first question is whether to do this using mainly static methods, or using an object instantiation block trick. Here's what the static version would look like: CypherQuery.start( node( "john", 0 )).returns( nodes("john") ) where "node" and "nodes" are static methods in StartExpression and ReturnExpression respectively. With full static imports it simply becomes: String q = start( node( "john", 0 )).returns( nodes("john") ).toString() To avoid statics I've tried doing a version that uses object instantiation blocks instead, and then it looks like this: String q = new CypherQuery() {{ starts( node( "john", 0 ) ).returns( nodes( "john" ) ); }}.toString(); In this case the "starts" method is a protected method in CypherQuery, and "node" and "nodes" are also protected methods in CypherQuery that returns expressions to be used in starts() and returns() respectively. Statics: Pro: Very compact syntax Con: need to do extensive static imports for it to be compact Instantiation block: Pro: No static imports Con: Slightly more verbose The second design decision has to do with path declarations. Here are the two options: 1) path("r").from("x").optional().out("KNOWS").to("y") vs 2) path("x",Direction.OUT, "r","KNOWS", "y") or path("x","y").direction(OUT).name("r").relationship("KNOWS") With multi-path scenarios it becomes: path("r").from("x").to("y").path("p").to("z") vs path("x",ANY,"r","y").path(ANY, "z").relationship("p") i.e. (x)-[r]-(y)-[p]-(z) 1): Pro: very explicit about what each parameter means Con: very explicit about what each parameter means 2) Pro: all-in-one-go (compact) Con: all-in-one-go (hard to know what each means) And that's about it I think! Please have a look at it, and if you have thoughts on the above, or any of the other design decisions, please let me know. regards, Rickard -- Rickard Öberg Developer Neo Technology Twitter: @rickardoberg, Skype: rickardoberg _______________________________________________ Neo4j mailing list [email protected] https://lists.neo4j.org/mailman/listinfo/user
