My favorites | Sign in
Project Home Downloads Wiki Issues Source
Search
for
Configuration  
Updated May 20, 2011 by aivar.annamaa@gmail.com

Basic usage of Alvor is enabled without any configuration, but with project-specific settings make Alvor's usage more convenient and/or more precise.

Project configuration

All configuration is done project-wise:

  • right-click your Java project
  • select "Properties"
  • open "Alvor SQL checker" property page or any of its sub-pages
  • configuration will be saved in ".alvor" file in project root

"Hotspots" property page

Here can should specify how to find the strings containing SQL. You should list the methods which must take correct SQL as argument. Relevant JDBC methods are already filled in -- add more cases if you use some abstraction library around JDBC.

"Checking" property page

Here you can specify how to check found strings -- they can be either thested against actual database schema or just syntax-checked. When a test database is configured, then SQL strings are tested by performing "Connection.prepareStatement" on given database. If no database is specified, then strings are checked according to built-in SQL grammar.

Annotating source-code in case of false-alarms

In certain cases of conditional SQL construction, Alvor detects possibility for erroneous SQL, but actually this will not occur because the nature of the test used in condition. Alvor's string analysis is not fully "path-sensitive", therefore in these cases false-alarms are unavoidable.

In order to get rid of false-alarm markers in "Problems" view, programmer can use @SuppressSQLChecker javadoc annotation on the method containing problematic hotspot. Example:

/**
 *  @SuppressSQLChecker
 */
private MInvoiceLine[] getLines (String whereClause) {
   ...
}

Sometimes it's possible to overcome a false-alarm without abandoning most of the checking done by Alvor. Following snippet presents a string method which is used for constructing required number of question marks for inclusion in SQL strings. Unfortunately, the constructions used can not be evaluated without false alarm. Here, the solution is using another annotation (@ResultForSQLChecker) for giving an example which represents the possible strings generated by this method:

/**
 * @ResultForSQLChecker (?, ?, ?)
 */
public static String getQuestionMarksForQuery(int number) {
    StringBuffer sb = new StringBuffer();
    if (number > 0) {
      sb.append(" (");
      for (int i = 0; i < number; i++) {
        sb.append('?');
        if (i != number - 1) {
          sb.append(", ");
        }
      }
      sb.append(") ");
    }
    return sb.toString();
}


Sign in to add a comment
Powered by Google Project Hosting