[Mulgara-dev] TransactionalAnswer not closed

[Andrae Muys]

On 10/02/2007, at 9:00 PM, Life is hard, and then you die wrote:
>     SELECT $email FROM ... WHERE ( and [info:doi/10.1371/ 
> preferences10536/topaz-plosone ... $prefn $_from] [$prefn ...  
> "email" $_from] [$prefn ... $email $_from] [$user <mulgara:is>  
> info:doi/10.1371/account/10536 $_from] [$pref <mulgara:is> info:doi/ 
> 10.1371/preferences10536/topaz-plosone $_from])
>
> Now the query runs beautifully and quite fast.

Heh, and will even give you the correct answer - without $pref in the  
select clause of the outer query the $perf in the subquery was an  
independent variable, so you would have been seeing spurious results.

> I guess this is sorta documented:
>
>   Subqueries nest inside select by binding variables in the subquery
>   where clause to the outer select clause.

mmm I think that could be better worded.

> But it seems, from a user perspective, a bit annoying - I suppose
> there's a good reason why all variables that are "passed" to the
> subquery have to be listed in the select clause?

There are two problems - the first is that it doesn't work with the  
semantics we use to provide a logical interpretation of an Answer, we  
would have to define the interpretation of a subquery wrt the  
unprojected result of the outer Answer.  The problem this introduces  
is that due to the 1-N relationship between the projected result and  
the unprojected result, associating subqueries with the unprojected  
result would result in N subquery results per projected row.  The  
result of a subquery in the query would no longer be a sub-Answer,  
but a Multiset of sub-Answers.

The second is that the way subqueries are implemented corresponds to  
their definition wrt the projected result.  By the time we evaluate  
subqueries we have eliminated the non-projection attributes and  
therefore don't have access to the where clause results of the outer- 
query.

Of course the implementation could be changed, but getting the  
semantics right would be a rrpita - and we would expect to see users  
wondering why the design couldn't have been simpler. ;)

> P.S. for the modified query to actually work without throwing a
>      heap-error I needed to apply the ItqlInterpreterBean patch too
>      which closes the subanswers correctly.

mmm was that patch posted to the list?  I don't see anything about  
that in the svn repository logs, so I suspect it hasn't been fixed in  
trunk.  If it hasn't been mailed to the list, could you post it and  
we'll get it applied to trunk ASAP.

Andrae

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