The “OR” queries are definitionaly one big benefit to attaching facets to predicates, but there are more. For example, I could also use facets as a shorthand to expand a subset of predicates in my results block. So let’s say I have a set of predicates related to “alerts”…such as “alertSent”, “alertMessage”, “alertSentTime”, “alertCreatedTime”. Instead of writing:
{
alertSent
alertMessage
alertSentTime
alertCreatedTime
}
I could have attached the facet “category: alertPredicates” to each of these schema items. Then I can expand them in the result block like this:
{
expand(facet(category: alertPredicates))
}
Another use case is if I wanted to return an edge as well as a name and descrpition of an edge (to provide a detailed explanation of the edge contents in the query results themselves). If I’m retrieving a “business requirement”, I could write something like:
{
humanReadablePredicateName: facetValue(businessRequirement, name)
humanReadablePredicateDescription: facetValue(businessRequirement, description)
businessRequirement
}
Actually, for us, these predicates will always need to be resolved at runtime. This is because new predicates will be created by users - eventually there will be thousands of predicates. The schema definitions will be auto-generated based on the users’ selections (such as whether the predicate is a string or a number), and run against the dgraph database to create that predicate in the dgraph schema. So corresponding queries on the “name” category, will include a set of underlying predicates that exist only as application meta-data, not anywhere in our code itself.