Graphs in RavenDB: Query Results
Should a document be allowed to be bound to multiple aliases in the query results, or just one? Let’s talk about what the actual problem is.
Join the DZone community and get the full member experience.
Join For FreeWe run into an interesting design issue when building graph queries for RavenDB. The problem statement is fairly easy. Should a document be allowed to be bound to multiple aliases in the query results, or just one? However, without context, the problem statement in not meaningful, so let’s talk about what the actual problem is. Consider the graph on the right. We have three documents, Arava, Oscar and Phoebe, and the following edges:
- Arava Likes Oscar
- Phoebe Likes Oscar
We now run the following query:
This query asks for a dog that likes another dog that is liked by a dog. Another way to express the same sentiment (indeed, how RavenDB actually considers this type of query) is to write it as follows:
When processing the and expression, we require that documents that match to the same alias will be the same. Given the graph that we execute this on, what would you consider the right result?
Right now, we have the first option, in which a document can be matched to multiple different aliases in the same result, which would lead to the following results:
Note that in this case, the first and last entries match A and C to the same document.
The second option is to ensure that a document can only be bound to a single alias in the result, which would remove the duplicate results above and give us only:
Note that in either case, position matters, and the minimum number of results this query will generate is two, because we need to consider different starting points for the pattern match on the graph.
What do you think should we do in such a case? Are there reasons to want this behavior or that and should it be something that the user selects?
Published at DZone with permission of Oren Eini, DZone MVB. See the original article here.
Opinions expressed by DZone contributors are their own.
Comments