Oops my bad, I am associating document ordering with sorting.
Although tracing through the code, the Iterator that is being
used is the WalkingIteratorSorted. The problem (in this case)
is around line 474 of NodeSequence#nextNode where there
is a test for isDocOrdered which fails and then calls
addNodeInDocOrder. That function compares the NodeID's
and ignores them if they are equal.
John G
Joseph Kesselman wrote:
> Uhm....
>
> The DTM document is not "always sorted". Our base implementation of DTM
> happens to number nodes in document order, but doesn't have to "sort" them
> because that happens to be the order in which the models are being built.
> (For SAX, that's because this is the order in which events arrive; for
> DOM, it's related to the difficulty of associating DOM nodes with DTM Node
> Handles except via a sequential scan.) There isn't a requirement that this
> ordering be used, as long as the implementation can find some way to
> answer the question of whether one node is before another when the XPath
> or XSLT process requires that information.
>
> Some XPath and XSLT operations do require that data be presented in
> document order (or, in a few cases, reverse document order) even when that
> isn't necessarily the order in which it was generated. To achieve that, we
> may have to perform a sort operation.
>
> I agree that we _shouldn't_ be sorting if the underlying data asserts that
> it is already in the correct order, for obvoius reasons of efficiency. My
> understanding was that there is code to address just that optimization,
> but I haven't been able to find it in a quick scan of the iterators. (And
> of course if we are merging two sorted sets into another set sorted on the
> same principle, we ought to do an incremental merge-sort...)
>
> So we need to take a closer look at your example to understand why it's
> concluding that an explicit sort must be performed in one case and not the
> other. I would have expected/hopeed that in both cases we would realize
> that the results can be benerated andreturned in document order. The
> question is why we're failing to draw that conclusion in the longer
> path... and whether that is, in fact, what's happening, or if that path is
> instead causing read-ahead (and disruption of the SQL extension) by some
> mechanism other than sorting.
>
> ______________________________________
> Joe Kesselman / IBM Research
--
--------------------------------------
John Gentilin
Eye Catching Solutions Inc.
18314 Carlwyn Drive
Castro Valley CA 94546
Contact Info
[EMAIL PROTECTED]
Ca Office 1-510-881-4821
NJ Office 1-732-422-4917
