Re: limit per resource rethought...

On 2010-08-13, at 11:53, Axel Polleres wrote:
> 
> On 13 Aug 2010, at 11:29, Steve Harris wrote:
> 
>> On 2010-08-13, at 10:21, Axel Polleres wrote:
>> 
>>>> SELECT A,B FROM KNOWS k1 WHERE B IN (SELECT B FROM KNOWS k2 WHERE k1.A=k2.A LIMIT n);
>>> 
>>> Just adding a few notes here:
>>> 1)  LIMIT is actually not standard in SQL
>> 
>> That's true, but it's rather widely implemented. I think MS SQL was the last to hold out, and they added it recently.
>> 
>>> http://en.wikipedia.org/wiki/Select_%28SQL%29#Limiting_result_rows
>>> in ISO SQL:2008 FETCH FIRST should work...
>> 
>> That's just a standard way to write LIMIT, it doesn't alter the execution model.
>> 
>>> 2) this SQL version using IN here, actually rather amounts to allowing IN along with unary SELECTs in FILTERs for us...
>>>  which would reopen ISSUE-6 in which case the query would probably look be something like:
>>> 
>>>  SELECT ?A ?B WHERE { ?A :knows ?B FILTER ( ?B IN ( SELECT ?B1 WHERE {?A :knows ?B1} LIMIT n ) ) }
>>> 
>>> BTW, I acknowledge of course that this whole use case is kind of complementary to the original LIMIT per resource [1] use case
>> 
>> And you still won't get the behaviour you'd like, it's evaluated bottom-up. See my other mail.
> 
> Hmmm, I understood that FILTER's are always evaluated "per binding", i.e. the FILTER expression 
> is evaluated after the existing bindings have been replaced...

We don't have any semantics for that kind of subquery in SPARQL, but in SQL that's not what happens. The subquery is executed first, so the FILTER/WHERE would always see the same table against the IN.

> in that ontext, as for your other mail...
> 
>> Your query - though not really equivalent to a SPARQL-style subquery,
> 
> True, indeed, it would need subqueries allowed in IN in FILTERS with the mentioned behavior, i.e. 
> that existing bindings are "injected" in the FILTER before the subquery is evaluated.

Right, which would mean that part of our algebra as top-down, and part bottom-up. I suspect it would be very hard to specify that without introducing non-deterministic results.

>> and not legal SQL :) 
> 
> Not sure what you mean here? I tried out my SQL query in SQLite and it behaved as intended

OK, the table rename without AS, combined with use of uppercase for table names threw me.

- Steve

-- 
Steve Harris, CTO, Garlik Limited
1-3 Halford Road, Richmond, TW10 6AW, UK
+44 20 8439 8203  http://www.garlik.com/
Registered in England and Wales 535 7233 VAT # 849 0517 11
Registered office: Thames House, Portsmouth Road, Esher, Surrey, KT10 9AD

Received on Friday, 13 August 2010 11:04:03 UTC