BIND 10 #324: improve SQL data source performance

[BIND 10 Development]

#324: improve SQL data source performance
-------------------------------------+-------------------------------------
                   Reporter:  each   |                 Owner:  UnAssigned
                       Type:         |                Status:  assigned
  enhancement                        |             Milestone:
                   Priority:         |  Sprint-20120403
  medium                             |            Resolution:
                  Component:  data   |             Sensitive:  0
  source                             |           Sub-Project:  DNS
                   Keywords:         |  Estimated Difficulty:  5
  performance                        |           Total Hours:  0
            Defect Severity:  N/A    |
Feature Depending on Ticket:         |
  sqlite schema upgrade              |
        Add Hours to Ticket:  0      |
                  Internal?:  0      |
-------------------------------------+-------------------------------------
Changes (by stephen):

 * owner:  stephen => UnAssigned


Comment:

 Putting this back to !UnAssigned as I got sidetracked on #963 and never
 completed this ticket (or checked any files in).  As I am now away for
 over a week, someone else needs to complete it.

 Suggested changes for the src/lib/datasrc/sqlite3_*.* files are in the
 attached patch.  These changes get the version from the updated
 schema_version table, throwing an exception if the version is not 2.0.
 For the changes to work, all the databases used in the unit tests need to
 be upgraded to the new version of the schema.  It is suggested that the
 b10-dbutil utility in ticket #963 be used for the conversion.

 Note: the schema changes introduced by this ticket - essentially changing
 STRING columns to TEXT columns - should be accompanied by an increase in
 the schema version number.  The opportunity is being taken to change the
 schema_version table to hold two columns - "version" and "minor".
 "version" holds the major version number and is so named so that old code
 (that expects a single column named "version") will be able to access the
 table without generating an exception.  At the same time, the version
 number is being updated to 2.0.  This means that code that reads "version"
 from schema_version can do one of two things:
  * If it gets a value of 1, it assumes the database is at schema version
 1.0
  * if it gets a value other than one, it can interrogate the "minor"
 column for the minor version number.

-- 
Ticket URL: <http://bind10.isc.org/ticket/324#comment:16>
BIND 10 Development <http://bind10.isc.org>
BIND 10 Development