Transaction

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:

  • transaction properties
  • a list of events of the following types:
    • request
    • path
    • response

Common transaction properties include:

Property Description
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

Referencing transaction properties

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.

Referencing multiple transactions

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:

  • t1 does not have to be the first transaction in the session
  • t2 can occur before t1
  • t1 and t2 may not be consecutive
  • t1 and t2 can be the same transaction
  • t1 and t2 can be different transactions

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:

Transaction identifiers Constraint Meaning
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: session with two transactions

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: query showing all 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: query showing consecutive

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?