Re: limit per resource rethought...

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

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.

> and not legal SQL :) 

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

Axel

> 
> - 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 10:53:51 UTC