Recent changes to feature-requests

Substituting parameters in check files

ape — Sun, 23 Sep 2012 10:11:13 -0000

Something that would be incredibly useful would the the ability to pass parameters to DB Sanity which it would then substitute into the check files.

For example, say I'm doing a daily load into a database and want to check if today's load passed the DB Sanity suite. I could do something like:

./dbsanity ... myproject -D date=2012-09-23

In the tests XML I could write

...
<sql>SELECT foo FROM bar WHERE something_not_sane AND load_date=${date}</sql>
...

There may be other places it would be useful too:

Or:

Whitelist for defect types as command line parameter

Joachim Simon — Mon, 31 Jan 2011 12:56:40 -0000

With the current version it's already possible to white-list tables as command-line parameter, so that only checks on those listed tables are run. Likewise there should be a command-line parameter to white-list defect types. This would support the use-case of running only specific types, which for example are only the fast and basic tests for frequent execution, but also running a full test with also the slower running checks on for example something like a nightly build or a final test.
Also one could reduce the output to only the currently most relevant types during test case development.

Attached there is a svn patch file, containing a simple implementation of this feature.

Test Versioning

Volker Bergmann — Wed, 27 Oct 2010 07:34:32 -0000

When a test suite becomes very large (as in our case 300+ checks), versioning by a CMS system is not feasible any more. It is desirable to assign an applicability range to each test, e.g. 'from version 1.1.2 to version 2.0.2', 'until version 1.1.2' or 'since version 2.0.2'

Define check (failure) types

Volker Bergmann — Wed, 27 Oct 2010 07:29:42 -0000

When faulty entries have been found, it would be helpful to give the reviewer an indication of the type of faults found. This helps judging the severity and correction effort.

In conjunction with feature request 3096228, a default weight could be assigned to the check type which would help to easily get a first guess of the correction effort.

Typical failure types would be:
- Illegal column value
- inconsistent fields in one record
- missing descriptor entry
- Implicit foreign key constraint violation
- inconsistency in related entries

Weight failures

Volker Bergmann — Wed, 27 Oct 2010 07:22:53 -0000

After finding out that faults do exist in a database, an important consequent task is to estimate the effort to fix the faults. It could be helpful to assign a kind of weight to a failure which indicates the correction effort.

Limit failure report to N records

Volker Bergmann — Wed, 27 Oct 2010 07:18:15 -0000

If a large database table is completely messed up, the report that list the faulty entries can grow to a size of several hundred megabytes. This consumes time and disk space and possibly exceeds the capabilities of a browser.

A solution for the latter issue would be to split up the report over several pages, with each one containing N records.

But since the errors are likely to stem from one or few causes, it is legitimate to simply leave out entries in the report after a count of N has been reached.

The limit N should be easily configurable, e.g. as a command line argument.