BIND 10 #2575: implement DataSourceClient::deleteZone and its SQLite3 implementation

[BIND 10 Development]

#2575: implement DataSourceClient::deleteZone and its SQLite3 implementation
-------------------------------------+-------------------------------------
            Reporter:  jinmei        |                        Owner:
                Type:  task          |  jinmei
            Priority:  medium        |                       Status:
           Component:  data source   |  reviewing
            Keywords:                |                    Milestone:
           Sensitive:  0             |  Sprint-20130122
         Sub-Project:  DNS           |                   Resolution:
Estimated Difficulty:  3             |                 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):

 Thanks for the review.

 Replying to [comment:9 vorner]:

 > I think these comments are little bit confused. The first one says it
 should return `false`, but then there's `EXPECT_TRUE` after it. The second
 one says it should return `false`, but because it exists, however, if I
 understand it correctly, the zone actually doesn't exist at the time.

 Oops, sorry about that.  It was an error as a result of starting from
 a copy of an addzone test.  I think I've fixed it so it now makes
 sense.

 > This comment seems to be a copy-paste. I don't see anything failing in
 here.
 > {{{#!c++
 > TYPED_TEST(DatabaseClientTest, deleteZoneRollbackOnNotFind) {
 >     // attempt of deleting non-existent zone.  result in false
 >     const Name new_name("example.com");
 >     EXPECT_FALSE(this->client_->deleteZone(new_name));
 >
 >     // deleteZone started a transaction, but since it failed,
 >     // it should have been rolled back, and the next attempt should
 succeed
 >     this->allowMoreTransaction(true);
 >     EXPECT_TRUE(this->client_->deleteZone(this->zname_));
 > }
 > }}}

 In this case, it was really an intentional copy-paste; I also wondered
 whether "fail" is a good phrase to explain this case in
 `createZoneRollbackOnExists`, too, but interpreted "fail" as the
 transaction not committed (but rolled back).  But as pointed out now,
 I've rephrased both so that (IMO) it will make more sense.

 I made one additional behavior change, which should be trivial.

 > Also, what is the ticket to actually use it? Should there be python
 interface?

 #2576 and #2577 are expected to follow this ticket.

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