[ 
https://issues.apache.org/jira/browse/RYA-148?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15415935#comment-15415935
 ] 

Kevin Chilton commented on RYA-148:
-----------------------------------

Why is this a problem?

> 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)

Reply via email to