Saxon

Legacy ID: #3284774 Legacy Poster: Michael Kay (mhkay)

This one is tricky. It's a manifestation of a problem that's thrown up a number of bugs in the past: in the expression tree, a TupleSorter node can contain a Let expression that declares a variable, and a sort key that references the variable, on separate branches: in all other cases the references to a variable are all descendants of the Let expression that declares it. Immediate attempts to patch a solution haven't been successful, and as I'm about to take some time off I'll have to come back to it on my return. I think I need to take a more fundamental look at the design in this area to remove the structural problem. David Carlisle came up with a compile-time rewrite for "order by" expressions that would remove the need for tuples entirely, which would be a great step forward as it's very messy having to handle a construct internally that isn't present in the user-visible data model.

Legacy ID: #3291385 Legacy Poster: Michael Kay (mhkay)

Actually the solution seems to be quite simple. The TupleSorter contains a set of sort key definitions using a data structure inherited from XSLT in which each sort key definition contains information about the sort key including ascending/descending, collations, and of course the sort key expression itself. But actually it seems the sort key expression isn't used at run-time, because it's been incorporated into the expression that actually constructs the tuple to be sorted. The expression is used only at compile time, as something that creates a dependency. So the solution is to remove the actual sort key expression from this data structure. This greatly simplifies the compile-time logic of TupleSorter. As a patch, the simplest way of achieving this is to change the line at QueryParser 1450 from key.setSortKey(((SortSpec) sortSpecList.get(i)).sortKey); to key.setSortKey(StringValue.EMPTY_STRING); Perhaps you could check that this works for you before I publish it. (I've made a more extensive change to the code in my version and this seems to be OK.) Michael Kay

Legacy ID: #3293125 Legacy Poster: marcvc (marcvc)

Michael, the fix seems to resolve the issue with the original query, but there are some other sceanrios where we still see the NPE. Consider for example the following query as reproducable: declare function local:foo() { for $v in (1,2) return for $v in (1,2) let $cnt := count(doc("ITEMS.xml")//ITEMNO) where $cnt > 0 return <e>{$cnt}</e> }; local:foo() Thanks, Marc

Legacy ID: #3295474 Legacy Poster: Michael Kay (mhkay)

This query is working for me. It's possible that the patch state is no longer quite aligned, since I've been making a few improvements as well as the bug fixes I've published. I'm thinking in terms of issuing a 5.9.1 release that should clear things up - but I haven't decided the timing; obviously I want to get as many of the bugs out as I possibly can. Michael Kay

Legacy ID: #3295491 Legacy Poster: Kevin Rodgers (notorious_kev)

Since there hasn't been a 5.9 release, do you mean 5.8.1 as the bug fix version?

Legacy ID: #3295511 Legacy Poster: Michael Kay (mhkay)

No, I mean 8.5.1. Temporary dyslexia. Michael Kay