Tracing query execution

Wednesday, 27 June 2018 · 4 messages · last reply 29 Jun 2018
IB
Iwan Briquemont27 Jun 2018 23:03 #
Hello, I use BaseX mostly for boolean queries, I have a hardware database and I check if specific hardware support features I need. It works great but when something is not as expected, it's hard to find out the reason. E.g. given an expression like: $some-value = $some-list and (custom:predicate() or $x > $y) I would like to know why it's true or false. For now I add trace() manually on the subexpressions, rerun, add trace to more specific parts, etc. Ideally I would want to break down the query execution so it shows the values of subparts of the query to pinpoint why it is false, e.g. have an output like: $some-value = $some-list and (custom:predicate() or $x > $y) -> false()$some-value = $some-list -> true()$some-value -> 1$some-list -> (1, 2, ..., 10)custom:predicate() or $x > $y -> false()custom:predicate() -> false()... # It should also go inside the function$x > $y -> false()$x -> 10$y -> 11 Any ideas how it could be achieved? Looking at the code, maybe a debug() (like iter() or item()) method could be added to Expr objects which would trace the expression query, file, line and the result of the expression (or probably the first x characters of the result to avoid huge output)? With an xquery function which would trigger it. I also thought of modifying the query programmatically to add trace() calls but that seems overly complicated. Best regards, Iwan
FE
Fabrice ETANCHAUD28 Jun 2018 10:18 #
Hi Iwan, IMHO it is more a design issue than a tool issue. If you need to know exactly where a boolean expression is decided, You might have to implement a boolean algebra interpreter. You could even describe your questions in xml format, to be interpreted by a recursive function against your hardware corpus. That way you could implement rules like : All ancestors are ‘and’ operators and my current node is ‘false’ => ‘false’ All ancestors are ‘or’ operators’ and my current node is ‘true’ => ‘true’ And detect exactly where your expression is decided. This make me think of the MarkLogic stored query feature. Sorry I just thought about that a few minutes, I hope it helps, Best regards, Fabrice
Quoted text · Iwan Briquemont · 27 lines
De : BaseX-Talk [mailto:basex-talk-bounces at mailman.uni-konstanz.de] De la part de Iwan Briquemont Envoyé : mercredi 27 juin 2018 23:04 À : basex-talk at mailman.uni-konstanz.de Objet : [basex-talk] Tracing query execution Hello, I use BaseX mostly for boolean queries, I have a hardware database and I check if specific hardware support features I need. It works great but when something is not as expected, it's hard to find out the reason. E.g. given an expression like: $some-value = $some-list and (custom:predicate() or $x > $y) I would like to know why it's true or false. For now I add trace() manually on the subexpressions, rerun, add trace to more specific parts, etc. Ideally I would want to break down the query execution so it shows the values of subparts of the query to pinpoint why it is false, e.g. have an output like: $some-value = $some-list and (custom:predicate() or $x > $y) -> false() $some-value = $some-list -> true() $some-value -> 1 $some-list -> (1, 2, ..., 10) custom:predicate() or $x > $y -> false() custom:predicate() -> false() ... # It should also go inside the function $x > $y -> false() $x -> 10 $y -> 11 Any ideas how it could be achieved? Looking at the code, maybe a debug() (like iter() or item()) method could be added to Expr objects which would trace the expression query, file, line and the result of the expression (or probably the first x characters of the result to avoid huge output)? With an xquery function which would trigger it. I also thought of modifying the query programmatically to add trace() calls but that seems overly complicated. Best regards, Iwan
IB
Iwan Briquemont28 Jun 2018 10:52 #
I forgot to reply to the mailing list too. ---------- Forwarded message ----------
Quoted text · Iwan Briquemont · 139 lines
From: Iwan Briquemont <tracnar at gmail.com> Date: 2018-06-28 10:51 GMT+02:00 Subject: Re: [basex-talk] Tracing query execution To: Fabrice ETANCHAUD <fetanchaud at pch.cerfrance.fr> Hi Fabrice, Indeed that's another solution. I also thought about restricting the expression to a subset of what XQuery supports to implement what you describe. But then the information would be restricted to the expressions which follow that subset. Note that I do not need to know how it is decided per-se for my application, it is as a debugging feature. Behind the boolean expressions there are also some more complicated queries (like joining data from multiple sources), which is why I like to be able to use XQuery all the way. I think this kind of debugging would be useful for actual queries too. Regards, Iwan 2018-06-28 10:18 GMT+02:00 Fabrice ETANCHAUD <fetanchaud at pch.cerfrance.fr>: > Hi Iwan, > > > > IMHO it is more a design issue than a tool issue. > > If you need to know exactly where a boolean expression is decided, > > You might have to implement a boolean algebra interpreter. > > You could even describe your questions in xml format, to be interpreted by > a recursive function against your hardware corpus. > > > > That way you could implement rules like : > > All ancestors are ‘and’ operators and my current node is ‘false’ => ‘false’ > > All ancestors are ‘or’ operators’ and my current node is ‘true’ => ‘true’ > > And detect exactly where your expression is decided. > > > > This make me think of the MarkLogic stored query feature. > > > > Sorry I just thought about that a few minutes, > > I hope it helps, > > > > Best regards, > > Fabrice > > > > *De :* BaseX-Talk [mailto:basex-talk-bounces at mailman.uni-konstanz.de] *De > la part de* Iwan Briquemont > *Envoyé :* mercredi 27 juin 2018 23:04 > *À :* basex-talk at mailman.uni-konstanz.de > *Objet :* [basex-talk] Tracing query execution > > > > Hello, > > > > I use BaseX mostly for boolean queries, I have a hardware database and I > check if specific hardware support features I need. > > > > It works great but when something is not as expected, it's hard to find > out the reason. > > > > E.g. given an expression like: > > $some-value = $some-list and (custom:predicate() or $x > $y) > > > > I would like to know why it's true or false. > > For now I add trace() manually on the subexpressions, rerun, add trace to > more specific parts, etc. > > > > Ideally I would want to break down the query execution so it shows the > values of subparts of the query to pinpoint why it is false, e.g. have an > output like: > > $some-value = $some-list and (custom:predicate() or $x > $y) -> false() > > $some-value = $some-list -> true() > > $some-value -> 1 > > $some-list -> (1, 2, ..., 10) > > custom:predicate() or $x > $y -> false() > > custom:predicate() -> false() > > ... # It should also go inside the function > > $x > $y -> false() > > $x -> 10 > > $y -> 11 > > > > Any ideas how it could be achieved? > > Looking at the code, maybe a debug() (like iter() or item()) method could > be added to Expr objects which would trace the expression query, file, line > and the result of the expression (or probably the first x characters of the > result to avoid huge output)? With an xquery function which would trigger > it. > > > > I also thought of modifying the query programmatically to add trace() > calls but that seems overly complicated. > > > > Best regards, > > Iwan >
CG
Christian Grünin reply to Iwan Briquemont, 27 Jun 2018, 23:0329 Jun 2018 10:30 #
Hi Iwan, The prof:variables and prof:dump functions [1] give you some more freedom to look into your running code. A prof:debug function would be nice, and an additional debug() method could be a possible entry point. The drawback is that there are hundreds of iter(), item() and value() implementations in the code, and it would require rather big efforts to make it happen. Another option would be to set a debug flag and react on it every time an item is in the code is evaluated, but this could slow execution time (we already lost some time when we introduced a way to stop running queries via the QueryContext.checkStop function). More suggestions are welcome, Christian [1] http://docs.basex.org/wiki/Profiling_Module
Quoted text · Iwan Briquemont · 46 lines
On Wed, Jun 27, 2018 at 11:03 PM Iwan Briquemont <tracnar at gmail.com> wrote: > > Hello, > > I use BaseX mostly for boolean queries, I have a hardware database and I check if specific hardware support features I need. > > It works great but when something is not as expected, it's hard to find out the reason. > > E.g. given an expression like: > > $some-value = $some-list and (custom:predicate() or $x > $y) > > > I would like to know why it's true or false. > For now I add trace() manually on the subexpressions, rerun, add trace to more specific parts, etc. > > Ideally I would want to break down the query execution so it shows the values of subparts of the query to pinpoint why it is false, e.g. have an output like: > > $some-value = $some-list and (custom:predicate() or $x > $y) -> false() > > $some-value = $some-list -> true() > > $some-value -> 1 > > $some-list -> (1, 2, ..., 10) > > custom:predicate() or $x > $y -> false() > > custom:predicate() -> false() > > ... # It should also go inside the function > > $x > $y -> false() > > $x -> 10 > > $y -> 11 > > > Any ideas how it could be achieved? > Looking at the code, maybe a debug() (like iter() or item()) method could be added to Expr objects which would trace the expression query, file, line and the result of the expression (or probably the first x characters of the result to avoid huge output)? With an xquery function which would trigger it. > > I also thought of modifying the query programmatically to add trace() calls but that seems overly complicated. > > Best regards, > Iwan

⚡Generated with XQuery