On 28/02/17 17:26, George News wrote:
On 28/02/2017 17:35, Rob Vesse wrote:
What you need to remember is that query execution is streaming lazy
evaluation. So each time you call hasNext()/next() the minimum amount
of work needed to compute the next answer, If any, is done. When you
convert the ResultSet into a list you’re doing all that work up front
once. When you iterate over the copied Data it is just a static list
of the previously computed results. Iterating over a static list has
very little overhead computationally, the downside is that it may
have a lot of memory overhead if you have a extremely large results.
This is a standard space time trade-off and you have to decide what
makes sense in your applications context.
Then between ResultSetFormatter.toList or ResultSetFactory.copyResults
the different is none, isn't it?
Different return types, both disconnect the results from the dataset.
One creates a List<QuerySolution>, the other returns a new
ResultSetRewindable.
It is better to not pass out the results - instead, pass in some code to
handle the results (e.g. using java8 lambda).
Andy
Sorry for the big thread.
Jorge
Rob
On 28/02/2017 16:19, "George News" <[email protected]> wrote:
On 28/02/2017 16:59, Andy Seaborne wrote:
[... snip ...]
In this sense, one option for including in Jena could be to
enable the option to create a QueryExecution with transaction
included, in order to avoid some issues like that.
That's what ResultSetFormatter.toList or
ResultSetFactory.copyResults do.
+1 but I don't want to iterate twice over the same list of data.
Although at the end I think it would be the easiest way to do it and
avoid extra issues ;)
Andy
