Raphael, I think that issue may be reporting on something slightly different. Filtering on Type should work for forward connections, but not reverse. So in your above example:
{
q(func: uid(0x1)) @filter(type(B)) {
uid
expand(_all_) {
uid
}
}
}
would work and return 0x1 and 0x2 in the resulting JSON response, but
{
q(func: uid(0x2)) @filter(type(B)) {
uid
expand(_all_) {
uid
}
}
}
would only return 0x2 Same query aside from the UID, type filter is just fine in the forward direction, but doesn’t work in the reverse direciton. I can add this to that issue, but I think it’s fundamentally a different problem.
As for why we aren’t using facets for this, that’s actually where we originally started, but since facets are not indexed, it presented a very possible bottleneck for our use case. I haven’t outline all the details of our particular strategy for versioning, but shoving in the extra node in the middle gets us around the indexing issue.
We can explicitly build a query that has all the predicates for the types on a node, but we were trying to avoid the added latency of an extra query to determine what predicates to build. That’s the only other solution we came up with, but the type filtering would result in simpler queries to dgraph, which we feel makes things a bit easier to follow, debug, and maintain.