[
https://issues.apache.org/jira/browse/RYA-148?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15416169#comment-15416169
]
ASF GitHub Bot commented on RYA-148:
------------------------------------
GitHub user kchilton2 opened a pull request:
https://github.com/apache/incubator-rya/pull/65
RYA-148 Fixed a bug where Joins would write the same binding set with…
… different visibility orders depending on which child node the new result
appeared on.
You can merge this pull request into a Git repository by running:
$ git pull https://github.com/kchilton2/incubator-rya RYA-148
Alternatively you can review and apply these changes as the patch at:
https://github.com/apache/incubator-rya/pull/65.patch
To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:
This closes #65
----
commit b7d3f80ab0ffa0a39eba110da7011613aa7be862
Author: Kevin Chilton <kevin.chil...@parsons.com>
Date: 2016-08-10T22:47:35Z
RYA-148 Fixed a bug where Joins would write the same binding set with
different visibility orders depending on which child node the new result
appeared on.
----
> Normalize Column Visibilities in Fluo Table
> -------------------------------------------
>
> Key: RYA-148
> URL: https://issues.apache.org/jira/browse/RYA-148
> Project: Rya
> Issue Type: Bug
> Components: dao
> Affects Versions: 3.2.10
> Reporter: Caleb Meier
> Assignee: Kevin Chilton
> Priority: Critical
> Fix For: 3.2.10
>
>
> 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.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
