[Mulgara-dev] Fwd: Bug list and versions

[Life is hard, and then you die]

On Tue, Nov 14, 2006 at 10:42:28AM +1000, Andrae Muys wrote:
> 
>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?

Sort-of like an outer-join, yes; not sure it's really like 'optional'.
As explained in the other email, the general form is

  ...pre-condition-on-a-and-b... and
  ((
    condition1-on-b and
    $t <#is> '0'
   ) or (
    condition2-on-b and
    $t <#is> '1'
   ) or (
    condition3-on-b and
    $t <#is> '2'
  ))

So the $t is to know which or-term(s) actually matched. In the error
case, one of the conditions is empty, leaving only the <#is> clause.

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

Great. This makes a lot of sense, and is how I've assumed it to be.

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

That makes sense.

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

We haven't reached the detailed query performance-optimization stage
yet, so this is good to know. Luckily this particular query is not
very performance sensitive.

>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'.

Ah, I see. So in the more general case I could use

  select $b $a
    subquery(select '0' from <...> where condition1-on-b) 
    subquery(select '1' from <...> where condition2-on-b) 
    subquery(select '2' from <...> where condition3-on-b) 
  from <rmi://localhost/server1#test>
  where
    ...pre-condition-on-a-and-b...

That's good to know.

[snip]
>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.

I wanted to check here before opening a bug. Done:
http://mulgara.org/jira/browse/MGR-34


  Cheers,

  Ronald