Mulgara

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?

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 ]

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.

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.

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

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.

Downgraded from critical to major as workaround does exist (just provide suitable <mulgara:is> bindings to avoid non-union-compatible disjunction).

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

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.

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

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

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