TdRules - Release Notes

Release Notes

New Features

In addition to the features originally described in the articles, the latest version supports the following features:

New Features

Qualified table names

The general form of a table identifier is a qualfied name in the form [[catalog.]schema.]name. Usually, a given catalog and schema are taken by default so as in most of queries table identifiers are not qualified. As of version 1.2.57.0 qualified table names are supported. For instance, if you declare a table name as myschema.mytable, you may refer to a table like myschema.mytable or a column like myschema.mytable.mycolumn in the queries.

Case sensitivity of table/column identifiers

Table and column names are case insensitive, however in previous versions the table and column identifieres were changed to upppercase. As of version 1.2.57.0 identifiers are still case insensitive, but the case of each identifier is preserved as declared in the query and/or schema. Quoted identifiers (enclosed in double quotes) are also supported

Case expressions

A new mutation operator CSE (Case expressions) has been defined for:

• Case specification (simple case and searched case): CASE ... WHEN ... THEN ... ELSE ... END.- If there are more than one when clauses then (1) Each of the when clauses is removed and (2) The else clause is removed (if present). If there is a single when clause then the case expression is replaced by (1) the result in the where clause and by (2) the result in the else clause (if no else clause is present, an implicit NULL result is assumed).
• Case abbreviation: COALESCE(expr1,expr2...exprN): If N>2 then each of the expressions is removed. If N=2 then the entire clause is replaced by each of the expressions.
• Platform dependent case abbreviations: IFNULL (SQLServer) and NVL (oracle).- Same as COALESCE.
• Case abbreviation: NULLIF(expr1,expr2).- Same as COALESCE.

Cast specifications

• Cast specifications: CAST(expr AS datatype) .- The expr is mutated as usual, but datatype do not is mutated. The result is assumed to have the data type as indicated by datatype and nullability as indicate by expr.
• SQL Server cast: CONVERT(datatype,exp) .- Mutated like the standard CAST.

Functions

In addition to the aggregate functions (set function types) the following functions are supported:

• Absolute value: ABS(expr).- Is replaced by expr and -expr. If expr consists on only a term, the ABS mutation operator is not applied to expr.
• Round function: ROUND(expr,scale).- The only mutation operator applied to scale is UOI.

Unknown Functions

Any other function-like expression in the form f(args) such that fis neither an aggregate function nor any of the above functions is denoted as an unknown function and do not causes a parse error. Each of the args expressions (arguments) is mutated as usual. The result of f is assumed to have an unknown data type and not nullable. Unkwnown functions without arguments are supported as well (provided that they include the brackets).

String concatenation

The string concatenation using the concatenation operator (| |) is mutated by applying the leftop and rightop operator. The SQL Server syntax (using a plus operator) is also supported.

NL mutants for non nullable attributes in the LOI or ROI

Consider a join on two tables: table1 LEFT JOIN table2 on table1.a=table2.b. If there is a WHERE clause which allows rows in the outer increment and references any column in the outer increment such as WHERE table1.a='a' OR table2.b='b', the value table2.b may be null even if it is not nullable. In this case the NL mutants are generated for table2.b.

Derived tables in FROM clauses

A derived query is a query specification that behaves like a physical table or view. Derived tables are now supported and mutated in the same way than the main query.

The derived query may have a table alias and a derived column list in the form: ( <derived_query> ) [ [AS] <table_alias> [ ( <derived_column_list> ) ] ]

SQL86 inner and outer joins

The SQL86 standard specifies the inner joins by separating the tables by commas and specifying the join conditions in the where. When a query includes this type of joins, it is mutated in the usual way and other mutants are added for the join. These mutants are obtained by applyiing the usual join operators to a transformed query which replaces every SQL86 join by its SQL92 equivalent (the join conditions are removed from the WHERE and an INNER JOIN with the join conditions is placed instead of the comma. The kind of join conditions supported are equijoins (one or more conditions in the form a=b, where a and b are columns that belong to each of the joined queries.

The SQL86 standard does not specify outer joins. However, there are some DBMS vendor specific ways to indicate outer joins. Given a join condition in the WHERE over columns a and b of the joined tables, the following outer joins are supported:

• Oracle: a = b (+) (left), a (+) = b (right)
• SQL Server: a *= b (left), a =* b (right)

These joins are mutated in the same way than the SQL86 inner joins, but the join is first transformed into LEFT or RIGHT.

Equivalent mutants

Equivalent mutants in joins with foreign keys

Assume that tables T and U are joined, and there is a foreign key on the joined columns from T to U. Then the following equivalent mutants are detected:

• INNER JOIN is equivalent to LEFT JOIN
• FULL OUTER JOIN is equivalent to RIGHT JOIN

A symmetric situation is given for a foreign key on the joined columns U to T.

Equivalent mutants in joins when where conditions can't return any LOI/ROI column

Consider a join on two tables: table1 INNER JOIN table2. If the WHERE clause requires a value in table2.x to be true or false (but not null), the mutation to LEFT JOIN is equivalent, as it returns all rows from the INNER JOIN, and does not return any row from the Left Outer Increment (LOI) because of table2.x must be not null in order to satisfy the WHERE condition.

Equivalent mutants in GROUP BY

If for any table the  attributes in the GROUP BY contain all its primary keys and some other non key attributes, the mutants are not generated for these on key attributes (because they are dependent on the primary keys).

Platform dependent features

System variables

The following SQL92 System Variables are supported: CURRENT_USER, USER, SESSION_USER, SYSTEM_USER, CURRENT_DATE, CURRENT_TIME, CURRENT_TIMESTAMP.

If the schema has been defined with the attribute dbms="oracle" the following System Variables and Oracle Pseudocolumns are supported: USER, CURRENT_DATE, CURRENT_TIMESTAMP, ROWNUM, ROWID, SYSDATE.

If the schema has been defined with the attribute dbms="sql server" the following System Variables and SQL Server System Functions are supported: CURRENT_USER, USER, SESSION_USER, SYSTEM_USER, CURRENT_TIMESTAMP.