Part of fix for XALANJ-2294 and XALANJ-2295.
Generated byte code previously looked up nodes to be retrieved by a reference
to the key or id function by cloning an IntegerArray containing the first set
of nodes and merging in subsequent nodes retrieved. The generated code
contained any required looping code to loop over nodes in a node set that
appeared in a call to key or id. The effect of all this was that every node in
the resulting node set was processed at least once, regardless of whether all
the node returned were actually used - they might not need to be if a positional
predicate is used, for instance.
The old KeyIndex.lookupId and KeyIndex.lookupKey are now deprecated, but
preserved for any previously compiled translets. Instead, new generated code
uses the KeyIndex.getKeyIndexIterator methods to get an iterator that will
return the nodes for a particular reference to the key or id function. The
nodes returned by KeyIndexIterator will be in document order with duplicates
filtered, so the DupFilterIterator that was previously created is no longer
necessary.
Also, fix for XALANJ-2292. The byte code generation assumed that if the
second argument to a reference to the key function was not a node set or a
string, that it had to be converted to a string. However, if the argument is
a parameter whose value is a node set, all the nodes in the node set should
play a role in computing the result of the function, not just the first.
The KeyIndex.KeyIndexIterator is responsible for processing the argument to the
key or id function, iterating over nodes in a node set if required, rather than
leaving that responsibility to generated byte code, because we don't generally
know whether the argument will be an iterator.
Reviewed by Christine Li (jycli () ca ! ibm ! com)
1 file changed
