You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@jena.apache.org by "Billig, Andreas" <an...@fokus.fraunhofer.de> on 2013/11/28 12:32:49 UTC
query evaluation determinism
Hello Team,
we exploring the good old "offset-limit-sorted"-issue. therefore our question: under which circumstances query evaluation is deterministic regarding
- the tdbstats-file
- transactions, i.e. adding or deleting triples
resp.
what we have to ensure if we want to have determinism - without using 'sorted by'?
resp.
which operations destroy determinism?
thanks in advance, Andreas
Re: AW: query evaluation determinism
Posted by Andy Seaborne <an...@apache.org>.
On 29/11/13 17:18, Billig, Andreas wrote:
> Thanks Andy, I will take a look at scala-caching if I have free time.
> Till then I conclude that the result order is the same between two write transactions - is this right ?
> Andreas
Within a read transaction, usually yes (unless you call RAND, NOW etc!)
even if a later write transaction starts. TDB read transaction are
serializable; there no lesser level needed. (You shouldn't really rely
on it though, other system may differ, but sometimes you have to.)
Andy
>
>
>
> ________________________________________
> Von: Andy Seaborne [andy@apache.org]
> Gesendet: Donnerstag, 28. November 2013 18:18
> An: users@jena.apache.org
> Betreff: Re: query evaluation determinism
>
> On 28/11/13 11:32, Billig, Andreas wrote:
>> Hello Team,
>>
>> we exploring the good old "offset-limit-sorted"-issue. therefore our
>> question: under which circumstances query evaluation is deterministic
>> regarding - the tdbstats-file - transactions, i.e. adding or deleting
>> triples
>
> After a change, all bets are off. The exact internal order will depend
> on what indexes were used and it's hard to predict how updates affect
> that. If full sorted results, then the order of evaluation is as per
> the ORDER BY.
>
> Within a read transaction, you don't see any change.
>
>>
>> resp. what we have to ensure if we want to have determinism - without
>> using 'sorted by'? resp. which operations destroy determinism?
>>
>> thanks in advance, Andreas
>>
>
> There is this experimental code (which is in scala):
>
> http://svn.apache.org/repos/asf/jena/Experimental/sparql-cache/
>
> It looks at a query, and can remove the LIMIT/OFFSET. It caches the
> result then reapplies the LIMIT/OFFSET. So next time , the query is
> cached and it's just a slice.
>
> Andy
>
AW: query evaluation determinism
Posted by "Billig, Andreas" <an...@fokus.fraunhofer.de>.
Thanks Andy, I will take a look at scala-caching if I have free time.
Till then I conclude that the result order is the same between two write transactions - is this right ?
Andreas
________________________________________
Von: Andy Seaborne [andy@apache.org]
Gesendet: Donnerstag, 28. November 2013 18:18
An: users@jena.apache.org
Betreff: Re: query evaluation determinism
On 28/11/13 11:32, Billig, Andreas wrote:
> Hello Team,
>
> we exploring the good old "offset-limit-sorted"-issue. therefore our
> question: under which circumstances query evaluation is deterministic
> regarding - the tdbstats-file - transactions, i.e. adding or deleting
> triples
After a change, all bets are off. The exact internal order will depend
on what indexes were used and it's hard to predict how updates affect
that. If full sorted results, then the order of evaluation is as per
the ORDER BY.
Within a read transaction, you don't see any change.
>
> resp. what we have to ensure if we want to have determinism - without
> using 'sorted by'? resp. which operations destroy determinism?
>
> thanks in advance, Andreas
>
There is this experimental code (which is in scala):
http://svn.apache.org/repos/asf/jena/Experimental/sparql-cache/
It looks at a query, and can remove the LIMIT/OFFSET. It caches the
result then reapplies the LIMIT/OFFSET. So next time , the query is
cached and it's just a slice.
Andy
Re: query evaluation determinism
Posted by Andy Seaborne <an...@apache.org>.
On 28/11/13 11:32, Billig, Andreas wrote:
> Hello Team,
>
> we exploring the good old "offset-limit-sorted"-issue. therefore our
> question: under which circumstances query evaluation is deterministic
> regarding - the tdbstats-file - transactions, i.e. adding or deleting
> triples
After a change, all bets are off. The exact internal order will depend
on what indexes were used and it's hard to predict how updates affect
that. If full sorted results, then the order of evaluation is as per
the ORDER BY.
Within a read transaction, you don't see any change.
>
> resp. what we have to ensure if we want to have determinism - without
> using 'sorted by'? resp. which operations destroy determinism?
>
> thanks in advance, Andreas
>
There is this experimental code (which is in scala):
http://svn.apache.org/repos/asf/jena/Experimental/sparql-cache/
It looks at a query, and can remove the LIMIT/OFFSET. It caches the
result then reapplies the LIMIT/OFFSET. So next time , the query is
cached and it's just a slice.
Andy