Retrospective 6.1 - Extended Retrospective Query Language RQL and filter improvements

As an experienced Retrospective user, you are probably already familiar with custom columns and have some knowledge of Retrospective Query Language (RQL). For the others, I would like to briefly explain these concepts in advance because the main features introduced with Retrospective 6.1.0 are based on them.

Log data found during the search and monitoring process is displayed in the Retrospective result table within a predefined set of columns such as "Date/Time", "Level", "Data" and so on.

Custom Columns

In order to have the most attracting cutouts of your log data displayed in individual new columns, you should define custom columns. Besides giving the column a name, you need to tell Retrospective, how to collect the data that shall appear in corresponding cells. You do this by defining Fields. In most cases there exist no strict rules on how to produce log data, hence the semantically same fields can appear in different places and with distinct formats all over your log file(s). Therefore, more than one Field can be assigned to the same Custom Column.

Retrospective Query Language (RQL)

The collected data can be filtered with the feature rich Retrospective Query Language (RQL). A query consists of one or multiple terms and groups. Terms and groups can be combined with Boolean operators to form a more complex query. RQL also supports single and multiple character wildcards ('*' and '?') within single terms and phrases. Such a query could look as follows.

Status:10 AND NOT URL:https*

By default, the entered terms and phrases are used to search for content found in the "Data" column. You can however filter any other column by typing the column name followed by an operator and the term. In Retrospective 6.0.0, the colon ':' was the only supported operator, which was quite a limitation. Such a query might have looked like this

("out of date" OR outdated) AND me*age

Naming Custom Columns

When a custom column contains a space in its name, it is not recognized by RQL. This may cause confusion because the reason is not always clear to the user.

Retrospective 6.1.0 now assists the user in creating RQL-compatible Custom Columns as follows:

  • When creating split columns, the user is offered the choice for naming them

    • The entered string is used as a prefix for naming the columns.

    • A warning bubble appears next to the text field. It informs the user that if he wants to use the column in an RQL query, he must avoid entering spaces.

  • In the Profile Viewer, custom columns containing a space are displayed together with a warning bubble. It informs the user that such columns cannot be used in RQL queries.

New RQL Operators

Retrospective 6.1.0 no longer supports the colon operator but introduced a range of useful new operators. These allow you to filter out exactly the information from the log data that is of real interest in order to complete your tasks even quicker.

= The equal operator tests if the column value and the filter term are equal.
The term may contain wildcards, even if the column is of data type "Number".
 
< The less than operator tests if the column value is less than the filter term.
The term must not contain wildcards.
 
<= The less than or equal operator tests if the column value is less than or equal to the filter term.
The term must not contain wildcards.
 
> The greater than operator tests if the column value is greater than the filter term.
The term must not contain wildcards.
 
>= The greater than or equal operator tests if the column value is greater than or equal to the filter term.
The term must not contain wildcards.
 

Using these new operators, an RQL query could now look as follows:

Path=*trace* AND (Code<10 OR Code=15) AND NOT Amount>10

Filtering with excluded original timestamp

So far, when the user excluded the original timestamps from the local filter, the navigation functions between filtered rows through move-up and move-down buttons was not available. In addition, there were various problems in exporting related data.

This feature got entirely reworked in Retrospective 6.1.0 and now behaves as expected.

  • The navigation functions between filtered rows now works perfectly regardless if the original timestamps are included or excluded from the local filter.

  • The number of filtered rows is now correctly reported.

  • The exported data is now also accurately filtered and search criteria in Excel files correctly underlined.

Other Improvements

As always, we spent great effort in improving the quality of our software. We updated the underlying Eclipse Target Platform together with different libraries and fixed a number of bugs. For further details, please consult the Retrospective 6.1.0 release notes.