Scott,
It looks like it may work. I think that AxesWalker#nextNode() is
getting confused because the node identity from row to row is the
same. There is this while loop at the end of the function that seems
to be causing the problem although I can't see the problem with the
logic. I will modify isNodeAfter() to compensate as a test.
Any other ideas ??
JohnG
[EMAIL PROTECTED] wrote:
> Hi John. OK, I think I have this working pretty well. I did a test with
> the mkay stylesheet and it does not seem to be sorting the nodes any
> longer.
>
> >From the commit note:
> Added isDocOrdered() and
> getAxis() to both DTMIterator and AxesWalker, and implemented
> appropriate overloads in derived or implementing classes. In
> FilterExprWalker
> return the contained DTMIterator's getAxis(). In WalkerIteratorSorted,
> implement canBeWalkedInNaturalDocOrder() function that is called
> from setRoot(...). If this function returns true, than don't sort the
> nodes
> in setRoot, and in all other respects treat this as if it is a simple
> WalkingIterator.
>
> So, in effect, the WalkingIteratorSorted is doing a second-tier runtime
> check to see if it really should be sorted, based on runtime information.
> While this adds some expense to WalkingIteratorSorted#setRoot, I'm hoping
> it will be made up easily in general stylesheets by doing less node sorting
> and caching.
>
> Please let me know what you think.
>
> The next step is to somehow throw an error if an XPath does occur where
> sorting is done. Can you easily determine that from the SQL extension? (I
> just don't see how this check can easily or even not-so-easily be done at
> stylesheet build time.)
>
> -scott
