Project

General

Profile

Bug #36

Basic query failure

Added by ronald - over 15 years ago. Updated almost 15 years ago.

Status:
Closed
Priority:
High
Assignee:
Category:
Mulgara
Target version:
-
Start date:
Due date:
% Done:

0%

Estimated time:
Resolution:
fixed

Description

The following setup demonstrates the problem:
<br/>

<br/>
&nbsp;&nbsp;&nbsp;&nbsp;drop &lt;<a href="local:///topazproject#test&gt;;">local:///topazproject#test&amp;gt;;</a>
<br/>
&nbsp;&nbsp;&nbsp;&nbsp;create &lt;<a href="local:///topazproject#test&gt;;">local:///topazproject#test&amp;gt;;</a>
<br/>

<br/>
&nbsp;&nbsp;&nbsp;&nbsp;insert 
<br/>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&lt;foo:bar&gt; &lt;foo:set&gt; &lt;user:joe&gt;
<br/>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&lt;foo:set&gt; &lt;topaz:implies&gt; &lt;bar:set&gt;
<br/>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&lt;foo:set&gt; &lt;topaz:implies&gt; &lt;bar:get&gt;
<br/>
&nbsp;&nbsp;&nbsp;&nbsp;into &lt;<a href="local:///topazproject#test&gt;;">local:///topazproject#test&amp;gt;;</a>
<br/>

<br/>
&nbsp;&nbsp;&nbsp;&nbsp;select $s $p $o from &lt;<a href="local:///topazproject#test">local:///topazproject#test</a>&gt; where (
<br/>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;$s $p $o 
<br/>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;and ($s &lt;mulgara:is&gt; &lt;foo:bar&gt;)
<br/>
&nbsp;&nbsp;&nbsp;&nbsp;) or (
<br/>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;($s $impliedBy $o and $impliedBy &lt;topaz:implies&gt; $p)
<br/>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;and ($s &lt;mulgara:is&gt; &lt;foo:bar&gt;)
<br/>
&nbsp;&nbsp;&nbsp;&nbsp;);
<br/>

<br/>
&nbsp;&nbsp;&nbsp;&nbsp;select $s $p $o from &lt;<a href="local:///topazproject#test">local:///topazproject#test</a>&gt; where (
<br/>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;$s $p $o 
<br/>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;or ($s $impliedBy $o and $impliedBy &lt;topaz:implies&gt; $p)
<br/>
&nbsp;&nbsp;&nbsp;&nbsp;) and ($s &lt;mulgara:is&gt; &lt;foo:bar&gt;);
<br/>

<br/>
The two queries are logically equivalent (the &lt;mulgara:is&gt; term is duplicated in the first query, and factored out in the second query). However, while the first query returns three statements, the second query only returns one. Specifically, the first query returns
<br/>

<br/>
&nbsp;&nbsp;&nbsp;&nbsp;&lt;foo:bar&gt; &lt;foo:set&gt; &lt;user:joe&gt;
<br/>
&nbsp;&nbsp;&nbsp;&nbsp;&lt;foo:bar&gt; &lt;bar:set&gt; &lt;user:joe&gt;
<br/>
&nbsp;&nbsp;&nbsp;&nbsp;&lt;foo:bar&gt; &lt;bar:get&gt; &lt;user:joe&gt;
<br/>

<br/>
but the second returns only
<br/>

<br/>
&nbsp;&nbsp;&nbsp;&nbsp;&lt;foo:bar&gt; &lt;foo:set&gt; &lt;user:joe&gt;
<br/>

<br/>

#1

Updated by Paula Gearon over 15 years ago

I need confirm this, but I have a theory...
<br/>
In the second query the initial part is:
<br/>

<br/>
$s $p $o or
<br/>
($s $impliedBy $o and $impliedBy &lt;topaz:implies&gt; $p)
<br/>

<br/>
Since the ($s $p $o) triple is all that is being selected then the part in parentheses would appear redundant.  Perhaps there is code that recognizes this and does the optimization before the mulgara:is predicate is applied?
#2

Updated by Paula Gearon over 15 years ago

The theory isn't looking too good.  However, the problem appears to be resolution order, if the constraint order is reversed, then the bug does not appear:
<br/>

<br/>
select $s $p $o
<br/>
from &lt;<a href="rmi://localhost/server1#test">rmi://localhost/server1#test</a>&gt;
<br/>
where (
<br/>
&nbsp;&nbsp;($s $impliedBy $o and $impliedBy &lt;topaz:implies&gt; $p)
<br/>
&nbsp;&nbsp;or $s $p $o
<br/>
) and $s &lt;mulgara:is&gt; &lt;foo:bar&gt;;
<br/>

<br/>
Result:
<br/>
[ foo:bar, foo:set, user:joe ]
<br/>
[ foo:bar, bar:get, user:joe ]
<br/>
[ foo:bar, bar:set, user:joe ]
#3

Updated by Andrae Muys - over 15 years ago

Looks like non-union compatible disjunctions strike again.
<br/>

<br/>
Note that the second query is attempting a join between the assignment and a NUC-disjunction.
<br/>

<br/>
Paul, note the use of the $p in the object position - this does mean the parenthesised expression is not redundant.
#4

Updated by ronald - over 15 years ago

Thanks to both of you for checking this out so quickly. So should we
<br/>
just be avoiding using 'or'? That would be a bit difficult, though.
#5

Updated by Paula Gearon over 15 years ago

I had a typo in the first comment....
<br/>
When I said &quot;would appear redundant&quot;, I should have said &quot;could appear redundant&quot;.  The current behaviour is clearly a bug.  I wondered if the resolver made this mistake.  I find that scenario less likely now that I know that it works if the terms are reversed.
<br/>
I was speculating out loud in case it prompted anyone to have an &quot;A-Ha&quot; moment.  :-)
#6

Updated by Andrae Muys - over 15 years ago

No need to avoid 'or', but it is worth avoiding non-union-compatible 'or'.
<br/>

<br/>
What this means is that there are variables in one term of the disjunction that do not appear in all of the others.
<br/>

<br/>
So 
<br/>

<br/>
$a &lt;:is&gt; &lt;foo&gt; or $a &lt;:is&gt; &lt;foo&gt; is fine.  but
<br/>
$a &lt;:is&gt; &lt;foo&gt; or $a &lt;pred&gt; $b is not.
<br/>

<br/>
The work around is to use the distributive-law to convert any POSOP... form query into SOP as per your first example above.
<br/>

<br/>
The only problem with this work around is that the query fragment will not join against other constraints containing $b properly as unbound should join successfully with anything, while with an explicit placeholder it will eliminate.  However for SOP form queries handle UNBOUND correctly.
#7

Updated by Andrae Muys - over 15 years ago

Downgraded from critical to major as workaround does exist (just provide suitable &lt;mulgara:is&gt; bindings to avoid non-union-compatible disjunction).
#8

Updated by Andrae Muys - over 15 years ago

Got it - this is not a non-union-compatible disjunction bug after all.
<br/>

<br/>
This is a bug in [[UnorderedProjection]] which can only be triggered in the presence of a conjunction/disjunction combination.
<br/>

<br/>
Specifically projection is being used to reorder the variables of its operand, without taking into consideration the affect this has on prefixing.  To see this, look at the implementation of beforeFirst() in [[UnorderedProjection]], while considering that the order of variables in the projection may not be the same as the order in its operand.
<br/>

<br/>
An initial fix is to materialise the operand when a reordering of variables is required.  The ultimate fix is to do this only if the reordering will invalidate a defined-prefix, as we don't care if the defined-prefix is reordered as long as any prefix variable is not reordered with respect to non-prefix variables.
<br/>

<br/>
It would be good to take the time to fully exploit the Annotations to provide transparent access to defineIndex and reresolve.
<br/>

<br/>

#9

Updated by Andrae Muys - over 15 years ago

Resovled in branches/nuc-disj revision <a href="http://mulgara.org/trac/changeset/231">231</a>.
<br/>

<br/>
Please test - if there are no reports of regressions in the next few days I'll merge over to trunk.
#10

Updated by ronald - over 15 years ago

This works for us. We tested the original query that lead to this bug report. Many thanks.
#11

Updated by ronald - over 15 years ago

Ooops, scratch that last comment - wrong bug report. Sorry. We're still in the process of verifying this one.
#12

Updated by ronald - over 15 years ago

Ok, for real now: we tested our full original query and the seems to be fixed. Thanks!

Also available in: Atom PDF