Critical Description
There is currently a bug in how the Rya Fluo Application handles column visibilities which leads to duplicate results in the Precomputed Join Tables. For example, consider a query that consists of a join which has StatementsPattern SP1 as a left arg and StatementPattern SP2 as a right arg. Suppose that a triple T1 comes in that matches SP1 and a triple T2 comes in that matches SP2. Also assume that T1 has visibility v1 and T2 has visibility v2. When the StatementPatternObserver processes T1, it joins the binding set associated with T1 (with visibility v1) with the binding set associated with T2 (with visibility v2). The result of the join is a binding set with visibility v1&v2. On the other hand, when the StatementPatternObserver processes T2, it produces the same binding set BS, but with visibility v2&v1. That is, the visibility of the StatementPattern bindingset being processed always comes first in the composite visibility formed from the join. This results in two copies of BS with the same visibility (just ordered differently). As a proposed fix, the visibilities should be combined in a manner consistent with how the StatementPatterns are ordered in the query. For example, always put the visibility of the left argument of the join first when forming the combined visibility. This will generate a default ordering of the composite visibility that won't lead to duplicates. In the above example, BS will have visibility v1&v2 regardless of whether T1 or T2 is processed first and the second copy that gets generated will overwrite the first, leading to no duplicate values.
Attachments
Issue Links
- links to
