Graphs in RavenDBI didn’t mean to build this feature!

time to read 2 min | 258 words

I was busy working on the implementation on filtering in graph queries, as discussed in my previous post. What I ended up implementing is a way for the user to tell us exactly how to handle the results. The actual query we ended up with is this:


And the key part here is the where clause, were we state that a and c cannot be the same dog. This also matches the behavior of SQL, and for that reason allow (predictably), that’s a good idea.

However, I didn’t just implement inequity, I implement full filtering capabilities, and you can access anything in the result. Which means that this query is now also possible:


I’ll let you a moment to analyze this query in peace. Try to de-chyper it (pun intended).

What this  query is doing is to compare the actual sale price and the regular price of product on a particular order, for products that match a particular set of categories.

This is a significant query because, for the first time in RavenDB, you have the ability to perform such a query (previous, you would have had to define a specific index for this query).

In other words, what graph query filtering brings to the table is joins. And I did not set out to build this feature and I’m feeling very strange about it.

More posts in "Graphs in RavenDB" series:

  1. (08 Nov 2018) Real world use cases
  2. (01 Nov 2018) Recursive queries
  3. (31 Oct 2018) Inconsistency abhorrence
  4. (29 Oct 2018) Selecting the syntax
  5. (26 Oct 2018) What’s the role of the middle man?
  6. (25 Oct 2018) I didn’t mean to build this feature!
  7. (22 Oct 2018) Query results
  8. (21 Sep 2018) Graph modeling vs. document modeling
  9. (20 Sep 2018) Pre-processing the queries
  10. (19 Sep 2018) The query language
  11. (18 Sep 2018) The overall design