[
https://issues.apache.org/jira/browse/RYA-148?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15417554#comment-15417554
]
ASF GitHub Bot commented on RYA-148:
------------------------------------
Github user isper3at commented on a diff in the pull request:
https://github.com/apache/incubator-rya/pull/65#discussion_r74458400
--- Diff:
extras/rya.pcj.fluo/pcj.fluo.app/src/test/java/org/apache/rya/indexing/pcj/fluo/app/IterativeJoinTest.java
---
@@ -0,0 +1,88 @@
+/*
+ * Licensed to the Apache Software Foundation (ASF) under one
+ * or more contributor license agreements. See the NOTICE file
+ * distributed with this work for additional information
+ * regarding copyright ownership. The ASF licenses this file
+ * to you under the Apache License, Version 2.0 (the
+ * "License"); you may not use this file except in compliance
+ * with the License. You may obtain a copy of the License at
+ *
+ * http://www.apache.org/licenses/LICENSE-2.0
+ *
+ * Unless required by applicable law or agreed to in writing,
+ * software distributed under the License is distributed on an
+ * "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
+ * KIND, either express or implied. See the License for the
+ * specific language governing permissions and limitations
+ * under the License.
+ */
+package org.apache.rya.indexing.pcj.fluo.app;
+
+import static org.junit.Assert.assertEquals;
+
+import java.util.Arrays;
+import java.util.Collection;
+import java.util.Collections;
+import java.util.Iterator;
+
+import
org.apache.rya.indexing.pcj.fluo.app.JoinResultUpdater.IterativeJoin;
+import
org.apache.rya.indexing.pcj.fluo.app.JoinResultUpdater.LeftOuterJoin;
+import org.apache.rya.indexing.pcj.fluo.app.JoinResultUpdater.NaturalJoin;
+import org.apache.rya.indexing.pcj.storage.accumulo.VisibilityBindingSet;
+import org.junit.Test;
+import org.junit.runner.RunWith;
+import org.junit.runners.Parameterized;
+import org.junit.runners.Parameterized.Parameter;
+import org.junit.runners.Parameterized.Parameters;
+import org.openrdf.model.ValueFactory;
+import org.openrdf.model.impl.ValueFactoryImpl;
+import org.openrdf.query.impl.MapBindingSet;
+
+/**
+ * Tests the methods of {@link IterativeJoin}.
+ */
+@RunWith(Parameterized.class)
+public class IterativeJoinTest {
+
+ @Parameters
+ public static Collection<Object[]> data() {
+ return Arrays.asList(new Object[][] {
--- End diff --
this just feels.....odd
> 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)
