BIND 10 #1329: Extend DatabaseAccessor to support adding diffs

[BIND 10 Development]

#1329: Extend DatabaseAccessor to support adding diffs
-------------------------------------+-------------------------------------
                   Reporter:         |                 Owner:  jinmei
  jinmei                             |                Status:  reviewing
                       Type:  task   |             Milestone:
                   Priority:  major  |  Sprint-20111108
                  Component:  data   |            Resolution:
  source                             |             Sensitive:  0
                   Keywords:         |           Sub-Project:  DNS
            Defect Severity:  N/A    |  Estimated Difficulty:  5
Feature Depending on Ticket:         |           Total Hours:  0
        Add Hours to Ticket:         |
                  Internal?:  0      |
-------------------------------------+-------------------------------------
Changes (by jelte):

 * owner:  jelte => jinmei


Comment:

 (very general note; we seem to be pretty inconsistent in using !/// and
 /!** notation for doxygen comments, even within single files. Certainly
 unrelated to this ticket, but perhaps we want to make this a bit more
 consistent. Especially for instance in database.h where the comment
 for DiffOperation uses !///, the code above and below it use /!**, and
 at some point everything is !/// again)

 I like the getStatement() approach, btw.

 Should we have some way of signaling whether journaling is supported
 by the datasource at all?

 Just one real comment, in sqlite3_accessor.cc, and about a (probably)
 temporary method anyway. So if we plan to ditch it, maybe we should
 only add some comments in the cc file regarding the potential issues
 below (in case it is taken as the base for whatever we write later).
 Or you can ignore the comments below here :)

 SQLite3Accessor::getRecordDiff()

 The return value of sqlite3_step should probably be checked for more
 than SQLITE_ROW or not (I am mainly thinking of SQLITE_ERROR). Not
 sure whether it should then drop the result and raise an error or keep
 the current behaviour of just returning what it found so far, but I am
 leaning towards the first (as one might get unexpected behaviour this
 way should something really bad be going on)

 BTW, I may be premature optimizing things here, but that interface of
 getRecordDiff could be more efficient if we pass it a vector instead
 of letting it return one. Unless of course we assume this is optimized
 away by the compiler. A drawback would be that it wouldn't be
 exception-safe on this level if the previous comment is taken into
 account, but handling that may be a caller-level issue. I am noting it
 because interfaces are much harder to change than code itself :)

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