When a user asks a question and the bot responds, we refer to the process as a transaction. This is what the user said, this is what the bot responded. But a transaction is more than that, of course. A transaction also records the entire process of how the bot came to respond as it did. More specifically, a transaction holds everything that happens from the point that a user input is received to the time the bot's response is returned.
Transactions contain the following parts:
Common transaction properties include:
|t.id||Unique identifier for transaction, actually the session ID appended with transaction index|
|t.duration||The amount of processing time from beginning to end of the transaction|
|t.index||The index of the transaction, starting with 0 for the first transaction|
|t.time||A timestamp for the transaction|
When referring to transaction properties in queries you must precede them with a transaction prefix. So if you want to view transaction IDs associated with a particular user input, you would reference the ID as transaction.id or t.id for short. The index property t.index is also useful, for example in locating consecutive transactions, as we show you further on in this page. Note: the transaction ID is the session ID plus the number of the transaction appended as a suffix. So if the session ID is B436C752217057D239BD04B5E55FDFF3 the transaction ID of the initial transaction is B436C752217057D239BD04B5E55FDFF3_0 and so on.
It is often necessary to refer to multiple different transactions in a query. So instead of referring to t.index you can add an additional identifier to distinguish the references, e.g. t1.index, t2.index, etc.
This kind of notation is fundamental to TQL, so it is important to understand exatly what the identifiers mean. If you refer to properties of t1, e.g. t1.id and t1.index the concerned properties must come from the same transaction. If you use t1.id and t2.index in your query, the concerned properties do not have to come from the same transaction, but they may.
Also, do not be mislead by the numeric nature of the identifiers. It has nothing to do with order of occurrence. You can think of the identifiers as symbolic names. If using t1 and t2 the following can be true:
You can however apply additional constraints to your query to assure that t1 and t2 do have specific locations in the session relative to each other. This table shows some ways to do it:
|t1, t2||t1.id != t2.id||t1 and t2 must be different transactions|
|t1, t2||t1.index == t2.index - 1||t2 must immediately follow t1|
|t1, t2||t1.index < t2.index||t1 must occur sometime before t2|
Let's look at some simple queries for this brief session. There are two transactions, the first with index 0, the second with index 1:
If we run a query using t1 and t2 to list pairs of indices in that session, TQL tries to fit t1 and t2 to all the possible permutations:
By adding a constraint to the query, in this case, requiring the first index to be one less than the second in the pair, we arrive at a more meaningful result:
This is just to demonstrate that the identifer used for the transaction is independent from the transaction's actual location in the session. TQL simply finds a way to match them in any way possible to the transactions making up the session.
Was this page helpful?