BIND 10 #2541: add addZone() interface for data source

[BIND 10 Development]

#2541: add addZone() interface for data source
-------------------------------------+-------------------------------------
            Reporter:  jinmei        |                        Owner:
                Type:  task          |  jinmei
            Priority:  medium        |                       Status:
           Component:  data source   |  reviewing
            Keywords:                |                    Milestone:
           Sensitive:  0             |  Sprint-20121218
         Sub-Project:  DNS           |                   Resolution:
Estimated Difficulty:  0             |                 CVSS Scoring:
         Total Hours:  0             |              Defect Severity:  N/A
                                     |  Feature Depending on Ticket:
                                     |  loadzone-ng
                                     |          Add Hours to Ticket:  0
                                     |                    Internal?:  0
-------------------------------------+-------------------------------------

Comment (by jinmei):

 Replying to [comment:10 jelte]:

 > > I made a few additional minor changes.  Please pull and check them.

 I made yet another cleanup commit.

 '''database_unittest.cc'''

 > > > > - I'd like to test the case where rollback happens.

 > > Can't we do this with (e.g.) SQLite3 and updater?  See also the
 > > previous point.
 >
 > Let's see, start an update, try a createZone() (should fail and roll
 back), then roll back the update and do createZone() again (should not
 fail)?

 Yes.

 > Added such a test, it still only tests the 'higher level' (i.e. if
 startTransaction() fails itself this test wouldn't notice it, but at least
 it'll show that after a failure it can still add zones.

 The added test (createZoneRollbackOnLocked) is fine.  By this we can
 confirm (that it results in exception and) exception safety of
 createZone(), which cannot be tested in other scenarios.  I don't see
 strong need for createZoneRollbackOnExists(), but I'm okay with having
 it too.

 One final comment:

 '''sqlite3_accessor_unittest.cc'''

 Shouldn't rollback be done before the final check?
 {{{#!cpp
     // New zone should not exist
     EXPECT_FALSE(accessor->getZone(new_zone).first);

     accessor->rollback();
 }}}
 I suspect even if another_accessor succeeded to add the zone
 (e.g. with backend support for more fine-grained lock) the other
 `accessor` would still not see the new zone unless it exits from the
 transaction.

 If I'm correct on this, please make the trivial fix and merge.

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