Graphs in RavenDBInconsistency abhorrence
In my previous post, I discussed some options for changing the syntax of graph queries in RavenDB from Cypher to be more in line with the rest of the RavenDB Query Language. We have now completed that part and can see the real impact it has on the overall design.
In one of the design review, one of the devs (who have built non trivial applications using Neo4J) complained that the syntax is now much longer. Here are the before and after queries to compare:
The key, from my perspective, is that the new form is more explicit and easier to read after the fact. Queries tend to grow more complex over time, and they are being read a lot more often than written). As such, I absolutely want to lean toward being readable over being terse.
The example above just show the extra characters that you need to write. Let’s talk about something that is a bit more complex:
Now we have a lot more text, but it is a lot easier to understand what is going on. Focus especially on the Lines edge, where we can very clearly separate what constitute the selection on the edge, the filter on the edge and what is the property that contains the actual linked document id.
The end result is that we now have a syntax that is a lot more consistent and approachable. There are other benefits, but I’ll show them off in the next post.
A major source of annoyance for me with this syntax was how to allow anonymous aliases. In the Cypher syntax we used, you could do something like:
There is a problem with how to express this kind of syntax of anonymous aliases with the Collection as alias mode. I initially tried to make it work by saying that we’ll look at the rest of the query and figure it out. But that just felt wrong. I didn’t like this inconsistency. I want a parse tree that I can look at in isolation and know what is going on. Simplifying the language is something that pays dividends over time, so I eventually decided that the query above will look this with the next syntax:
There is a lot of precedence of using underscore as the “I don’t care” marker, so that works nice and resolves any ambiguities in the syntax.
More posts in "Graphs in RavenDB" series:
- (08 Nov 2018) Real world use cases
- (01 Nov 2018) Recursive queries
- (31 Oct 2018) Inconsistency abhorrence
- (29 Oct 2018) Selecting the syntax
- (26 Oct 2018) What’s the role of the middle man?
- (25 Oct 2018) I didn’t mean to build this feature!
- (22 Oct 2018) Query results
- (21 Sep 2018) Graph modeling vs. document modeling
- (20 Sep 2018) Pre-processing the queries
- (19 Sep 2018) The query language
- (18 Sep 2018) The overall design
Comments
I like the longer syntax more - it is more self explanatory. The cypher syntax just looks like regex madness to me: Write once or use so much comments that the result is more verbose than a sane syntax. Maybe jou could offen a kind of converter or a Editor plugin to ease writing this?
Christian , It is indeed very similar to regex, and that was a worried. Given that we'll probably be debugging a lot of these going forward, it make a lot of sense to try to optimize for "what the heck is going on here".
We are going to be providing intellisense around that, mind.
Do aliases need to be required? Can it work like sql where aliases are optional? The only time you would need them is when referencing the same collection multiple times.
Taking the first example:
could be shortened to this as there is only 1 duplicate usage of Employees:
Employees would refer to the first usage, ReportsTo is unique, and boss can be used to refer to the second usage of Employees.
In the final example, is the location of the arrow (before the edge element instead of after is) deliberate or accidental?
I’d think it depends on your perspective which syntax you find more readable. I always felt more comfortable with cypher as opposed to SQL (more coherence), so naturally your more terse syntax is preferrable to me.
@Frank, keep in mind, since this is graphing features being added into an existing product, there is value in having the syntax be consistent in areas with RavenDB's existing query language. That impacts readability as well.
Ted, Following this post, I changed things up so you can do implicit aliases. Now:
match (Employees where id() = 'employees/7-A')-[ReportsTo]->(Employees as boss)
Will have
Employees
,Employees_ReportsTo
andboss
as aliases.Richard, No, that was a typo. Just fixed it, thanks
Comment preview