DB Sanity enables you to provide checks for all versions of your database application form a single source. So you do not need to mess with complicated 3rd party versioning systems and the traps of merging and branching. With DB Sanity it is as easy as this:
Each check can be assigned with a specification, on which application versions a check has to be applied. As an example, when you specify
| <check name="PERSON.FAMILY_NAME required" versions="[1.1.2,1.3]">|
select id, email from person where family_name is null
the check PERSON.FAMILY_NAME is applied to all versions from 1.1.2 to 1.3 (inclusively). Several version specification formats are supported (see below). A check without version assignment is applied to any version.
When invoking DB Sanity from the command line, you specify the version with the -a parameter (or --appversion), e.g.
dbsanity -a 1.2.3 mydb
Checks that do not apply to the current version, are marked as kipped in the report.
There is a wide range of options to specify the versions:
|Syntax ||Description |
|* ||All |
|1.1||Version 1.1 |
|1.1, 1.2||Versions 1.1 and 1.2|
|>=1.1||Version 1.1 and all subsequent ones|
|> 1.0 ||All versions after 1.0|
|< 2.0||All versions before 2.0 |
|<= 2.1||All versions until 2.1 (inclusive) |
|[1.1.2, 1.1.8] ||All versions from 1.1.2 to 1.1.8 |
|[1.1.2, 2.0[ ||All versions from 1.1.2 before 2.0 |
|]1.1.2, 2.0[||All versions after 1.1.2 and before 2.0 |
|[1.1, 1.3], [1.5, 1.8]||Versions 1.1 through 1.3 and versions 1.5 to 1.8|
|[1.1, 1.4[, ]1.4, 1.8] ||Versions 1.1 through 1.8, excluding 1.4 |
Version numbers can contain numbers, strings and dates. Dates must have the form yyyyMMdd. Supported version strings are snapshot < alpha < beta < rc < cr < final < ga < sp (rc: release candidate, ga: general availibity,Â sp: service pack).
Examples of supported version numbers:
1 = 1.0 = 1.0.0 = ...
1.0-alpha < 1.0-alpha2 < 1.0 < 1.0-sp1 < 1.0-sp2
Application version Query
Instead of providing the application number explicitly on each call, you can put a QueryVersionProvider configuration into the project's dbsanity.xml file, specifying a SQL query that reads version number information from the database:<versionProvider class='org.databene.jdbacl.version.QueryVersionProvider'>
<property name='query' value='select VERSION_NUMBER from VERSION_TABLE' />
VersionProvider Extension Interface
You can even implement your own Java components for retrieving the application version in different ways. Just take care, that the component has a public default constructor and provides any configurable setting with a set...() method. Example:
Â Â Â <property name='fileName' value='deployments.csv' />" +
Â Â Â <property name='row' value='3' />" +
Â Â Â <property name='column' value='2' />" +
Recommended further reading: FAQ