I’ve created a query that I thought would show which inputs users repeated consecutively, in which the user input wasn’t empty.
d t1.e.userInput: t1.e.userInput==t2.e.userInput, t1.index==t2.index - 1, t1.e.userInput!=""
It gets results, but upon closer examination, the inputs found were not repeated.
Shouldn’t this work? Or what alternative way could this be queried?
Thanks for any help!
Hi @Fred.Roberts ,
You can try replacing “t1.index == t2.index - 1” with “t1.e-{type==“request”}>t2.e” and put it before “t1.e.userInput == t2.e.userInput”. For example: d t1.e.userInput: t1.e-{type==“request”}>t2.e, t1.e.userInput==t2.e.userInput, t1.e.userInput!="" This will probably solve this problem.
Chunlin
Thanks, Chinlin! That really did the trick. Not sure I understand why though. I thought t1.e-{type==“request”}>t2.e would only assure that T2 came sometime after T1, but not necessarily directly subsequent. Shouldn’t the index constraint take care of that? (Apparently it doesn’t but I’m not sure why not).
I would expect them to be the same in this context too - is it possible something else changed between it working and it not working? (you could try switching just that bit back and see if it no longer gives you the expected results - to satisfy your (and my!) curiosity)
How did you verify that the results were wrong / right? (using la t1.e.userInput, t2.e.userInput : ... presumably would make it fairly clear? 
)
(Note: the rest of this reply is background / skip to vs index comparison - possibly that is already clear to you - read / don’t read at leisure but it won’t help the above confusion! )
There are differences between the index comparison and the “skip” constraint (see TQL Manual - teneo.ai), they will in many cases give different results (but not in this one)
“skip” will find the next matching thing (or previous if x <{ ... }- y is used), so could find matches in the same transaction, next one, or any future transaction - however it will only find 1 match (ish - see below)
t1.index == t2.index - 1 will only ever match neighbouring transactions, never the same transaction or further apart - but could match any number of times within that transaction pair
All transactions have 1 and only 1 type==response event, and you have specified t1.e.userInput which only exists on the response
So inquire will look for:
userInput (therefore must be type=="request")so in this case they are equivalent, the next match will always be in the next transition
you can appear to get multiple results from a single skip to, but this is not because the skip to is finding lots of targets / ends / t2 (in this case), it will only ever find the single next match
You can get many results however when there are multiple start events, or multiple t1 (in this case)
For example if you were not referencing t.e.userInput then the start would no longer be tied to being a request event, so you would get a result from every event in the start transaction:
la t1.id, t2.id : t1.e-{type=="request"}>t2.e order by t1.id asc
The above query will give 1 result per event in each t1 (964 results on the unspecified dataset I am looking at)
whereas requiring a userInput property:
la t1.e.userInput, t1.id, t2.id : t1.e-{type=="request"}>t2.e order by t1.id asc
or specifying that t1 is a request event:
la t1.id, t2.id : t1.e.type=="request", t1.e-{type=="request"}>t2.e order by t1.id asc
or in fact using the index comparison (because now you are looking for transactions not events!):
la t1.id, t2.id : t1.index == t2.index - 1 order by t1.id asc
… will all give a single result per transaction (65 in this dataset)
if so, hi! also:
using the index comparison (because now you are looking for transactions not events!)
what do I mean? well with this query:
la t1.id, t2.id : t1.index == t2.index - 1 order by t1.id asc
The result only requires transaction properties (the selector only specifies t.[something] not t.e.[something]), so Inquire will only look at individual transactions. If you now add that you want a property that exists on an event (t.e.[something]) then Inquire will look for matches in all events within the transactions, so adding t.e.type to the selection like this:
la t1.id, t2.id, t1.e.type : t1.index == t2.index - 1 order by t1.id asc
will get you right back up to 964 results!
Thank you very much, Roger. This was a nice response. I will take some time to work through all this step by step and also see if I can find other variations.