No trace execution point around main XQuery body expression
When trace code is injected into a query during query compilation, trace instructions are injected at strategic points, e.g. round expressions that construct new nodes, around the body of a function, around the branches of a conditional, etc. This is designed to enable a useful level of tracing if the injected code is used to trace execution.
There is no trace point around the main expression of a query, which makes things difficult for certain kinds of tracing application, e.g. one that wants to instrument timings or monitor code coverage.
This is being fixed by adding a new trace point with locationKind = XQUERY_BODY. The effect is that when a query is run with the -T option, there is an extra wrapper element around the entire trace output.
#1 Updated by Michael Kay over 2 years ago
- Status changed from Resolved to In Progress
I think we could consider a wider fix to this. The CodeInjector can decide which expressions it wants to wrap (or otherwise modify) and which it wants to ignore. There's therefore not really an issue with having the CodeInjector be invoked on a wider range of expressions; in the implementation of CodeInjector that we use for XSLT and XQuery tracing, we can ignore the calls in respect of expressions that we don't want to trace.
However, this feels a bit more like an enhancement than a bug fix.
#2 Updated by Michael Kay over 2 years ago
- Status changed from In Progress to Resolved
For the next major release I have done a significant revamp of the code injection and TraceListener mechanisms; this involves interface changes, so is not suitable for a maintenance release.
The code injection is now done as a complete pass over the completed expression tree, rather than being done on-the-fly during parsing; this means it has access to every node in the expression tree, not only to selected nodes.
At the same time I have simplified the information passed to the TraceListener, since it was doing a lot of extra work to maintain data structures that are now redundant, given that every expression node now has standardised access to its operands, to its retained static context, and to its source location.
Please register to edit this issue