Thank you very much, Leo, and thanks for your interest, Marc. An observation I made, and which turned out to be crucial to my concrete problem: caching: for $node at $pos in doc('otds-fti')/foo/bar return ... not caching: for $node at $pos in doc('otds-fti')/foo/bar/document{.} return ...
So the final step /document{.} turns the for loop into caching. Interestingly, the problem can be worked around very simply: not caching: for $node at $pos in doc('otds-fti')/foo/bar let $node := document{.} return ... I am very glad that the problem could be solved. Your pointing out the importance of the expression details
"and the XPath expression you used only contains child steps, which can be evaluated in document order without duplicates." helped me to make the revealing experiment.
Thanks again -Hans-Jürgen PS: Interestingly, the following variant is also not caching:
f:evaluate($expr, $context) { let $ctx := map{'': $context} return xquery:eval($expr $ctx) }; let $context := doc('otds-fti') for $node at $pos in f:evaluate('/foo/bar', $context) let $node := document{.} return ...
Leonard Wörteler leonard.woerteler@uni-konstanz.de schrieb am 23:12 Mittwoch, 18.März 2015:
Hi Marc,
Am 18.03.2015 um 21:08 schrieb Marc:
As I understand the first part of answer, you tell that when there is a user defined function Basex do cache, but after when you analyze the example, you tell that in this cxase there is no cache else there is a f:processNode function in the return.
Do I you don't understand?
well, kind of. When evaluating a call to a user-defined function (that was not inlined during compilation), both the arguments and the result of the call are fully evaluated and cached in memory. This is still the case in Hans-Jürgen's example.
As I understand his question however, he is mostly concerned about the (potentially very big) sequence of nodes that the `for` loop iterates over. I just pointed out that that sequence will not normally be cached by BaseX.
Hope that clears it up, chears, Leo