[Mulgara-dev] Fwd: Bug list and versions

[Andrae Muys]

Forwarded with permission:

Begin forwarded message:

> From: Andrae Muys <andrae at netymon.com>
> Date: 14 November 2006 10:08:49 AM
> To: "Life is hard, and then you die" <ronald at innovation.ch>
> Subject: Re: Bug list and versions
>
> On 13/11/2006, at 6:52 PM, Life is hard, and then you die wrote:
>>> On Oct 18, 2006, at 4:32 AM, Life is hard, and then you die wrote:
>> We've run into another problem which seems to be related to this. I
>> wanted to run it past you two before submitting a bug report. This
>> occurs on both Kowari 1.1.0-pre2 and Mulgara svn-head, but we do seem
>> to have a workaround for it.
>>
>> Here's the minimal set of instructions to reproduce this:
>>
>>     create <local:///topazproject#test>;
>>     insert
>>       <foo:one> <p:type> <t:p>
>>       <foo:one> <p:hasA> <bar:one>
>>       <foo:one> <p:hasB> 'mollusks'
>>
>>       <foo:two> <p:type> <t:p>
>>       <foo:two> <p:hasA> <bar:two>
>>       <foo:two> <p:hasB> 'mollusks'
>>
>>       into <local:///topazproject#test>;
>>
>>     select $a $t from <local:///topazproject#test> where $b  
>> <p:type> <t:p> and $b <p:hasA> $a and (($b <p:hasB> 'mollusks' and  
>> $t <http://mulgara.org/mulgara#is> '0') or ($t <http://mulgara.org/ 
>> mulgara#is> '1'));
>>
>> The select results in
>>
>>   QueryException thrown in resolve:
>>   org.mulgara.query.QueryException: Failed to resolve query
>>   Caused by: org.mulgara.query.TuplesException: Prefix failed to  
>> meet defined minimum prefix
>>
>> The current workaround is to ensure that all of those 'or' clauses
>> have at least one other constraint besides the <mulgara:is>
>> constraint, in which case things seem to work.
>
> select $a $t from <>
> where
>   $b <p:type> <t:p> and
>   $b <p:hasA> $a and
>   ((
>     $b <p:hasB> 'mollusks' and
>     $t <#is> '0'
>    ) or (
>     $t <#is> '1'
>   ))
>
> As far as I can tell it appears you are trying to perform some sort  
> of outer-join-like query here - roughly analogous to a SPARQL  
> optional?  It's an ingenious construction, and one I haven't seen  
> used before.  However with version 1.1, this construct is supposed  
> to work fine.  In 1.1 Simon Raboczi and I formalised iTql as a  
> tuples-algebra, and <mulgara#is> simply introduces a literal tuples  
> term into the query.  I am confident this is not the problem here,  
> again I suspect the behaviour of the UnboundJoin code in the  
> presence of the UNBOUND bindings generated by the non-union  
> compatible disjunction.
>
> I am fascinated by this, you are the first users I am aware of  
> making real use of NUC-disjunctions - almost everyone seems to  
> prefer to use subqueries to solve these sort of problems.  Part of  
> the reason for this is that the performance of NUC-disjunctions is  
> unavoidably poor.  Unfortunately, because you aren't selecting $b  
> you can't capture the optional restriction as a subquery in this  
> case - if you were you could use the following:
>
> select $b $a subquery(select
>            from <rmi://localhost/server1#test>
>            where $b <p:hasB> 'mollusks')
> from <rmi://localhost/server1#test>
> where
>   $b <p:type> <t:p> and
>   $b <p:hasA> $a
>
> Then $k0 will be empty where $t == '1', unconstrained where $t == '0'.
>
> Paul did also suggest:
>
> select $a $t
> from <local:///topazproject#test>
> where
>     $b <p:type> <t:p> and
>     (($b <p:hasA> $a and
>       $b <p:hasB> 'mollusks' and
>       $t <http://mulgara.org/mulgara#is> '0')
>      or
>     (($b <p:hasA> $a minus
>      $b <p:hasB> 'mollusks') and
>      $t <http://mulgara.org/mulgara#is> '1'));
>
> Which does do exactly what you want; avoids use of NUC-disjunction  
> and therefore the bug; and is going to be much more efficient when  
> joining against large datasets.  Still thank-you for identifying a  
> simple, repeatable test case for that NUC-disjunction bug.  I can't  
> seem to find a bug report covering the last email, have you created  
> a bug report for the non-union-compatible disjunction failure we're  
> seeing here?  If not then I do suggest you open a bug.
>
> Andrae
>
> -- 
> Andrae Muys
> andrae at netymon.com
> Principal Mulgara Consultant
> Netymon Pty Ltd
>
>

-- 
Andrae Muys
andrae at netymon.com
Principal Mulgara Consultant
Netymon Pty Ltd