+972 52-548-6969
Graphs in RavenDBI didn’t mean to build this feature!
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:
- (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
If your relationships do not carry any values on their own, then they aren’t 1st class citizens of your graph, and hence comparable to joins.
What I'm wondering about is how will this impact performance? The graph queries look like an amazing and powerful tool, but since you've started showing them to us I've been curious how you will implement it. Until now all queries were building upon lucene indexes underneath, how will this fit in and work?
Frank, We allow relations that are bare or have data. In both cases, by the way, you can filter on them. In the case above, we could define this further as
Lines( Discount != 0).Product, which would do the filter at the edge level for only those with a discount.Daniel, This is a bit complex, and I'll have a few posts on this. There are several strategies that we employ here. The brute force one will simply scan through the graph, but that is something that we want to avoid as much as possible, obviously. Better options are to use indexes as the source for the query, which simplify a lot of the overall complexity that you run into. Then, we run analysis on the actual query and can chose to do things in a more optimal way (replacing multiple steps with a query, for example).
Comment preview