BIND 10 #1781: update SQLite3Accessor updater internals to handle NSEC3

[BIND 10 Development]

#1781: update SQLite3Accessor updater internals to handle NSEC3
-------------------------------------+-------------------------------------
                   Reporter:         |                 Owner:  jinmei
  jinmei                             |                Status:  reviewing
                       Type:  task   |             Milestone:
                   Priority:  low    |  Sprint-20120417
                  Component:  data   |            Resolution:
  source                             |             Sensitive:  0
                   Keywords:         |           Sub-Project:  DNS
            Defect Severity:  N/A    |  Estimated Difficulty:  5
Feature Depending on Ticket:  NSEC3  |           Total Hours:  0
        Add Hours to Ticket:  0      |
                  Internal?:  0      |
-------------------------------------+-------------------------------------

Comment (by jinmei):

 Replying to [comment:10 jelte]:

 Thanks for the review.

 > regarding the TODO line in dnsmessage_test.cc ("TODO: maybe we should
 share this stuff"), I think we should have basic and flexible string-to-
 rr(set) functions in the base library :) (but for now this is fine)

 Ah, first off, that TODO was a leftover and should have been deleted.
 I cleaned it up in the branch.

 As for defining it in the base library, I wondered about the same
 thing and I tend to agree it makes more sense.  I guess this will be a
 topic in the general loader context.  But if you want I'll also create
 an explicit ticket for it.

 > database.h:
 >
 > addRecordToNSEC3Zone():
 > I suspect \exception list should also mention general database errors
 (which in other similar methods raise a DataSourceError)

 I'm not sure if I was explicitly aware of this specific exception, but
 basically I wanted to repeat the same description that was already
 described in the non-NSEC3 counterparts (instead, I referred to them
 from the NSEC3 specific methods as a general note).  But in this
 specific case I don't strongly oppose to repeating the same thing, so
 I revised the code as suggested.

 > On a slightly bikesheddier note, the name of this method would suggest
 to me it should be used for every record, if the zone happens to be
 NSEC3-signed. I'd prefer it named addNSEC3RecordToZone (even though it can
 also take RRSIGs, those are for NSEC3 as well).

 Yeah, I was not a great fan of the naming either.  I guess I in fact
 considered the option of addNSEC3RecordToZone and didn't like it
 either because it was also for NSEC3-covering RRSIGs.  More verbose
 name like addRecordToNSEC3NameSpace or addNSEC3RelatedRecordToZone
 would be clearer, but would probably be too long (I felt
 addRecordToNSEC3Zone might already look too long).

 In the end, none of the options seems to be obviously the best, so I
 accepted the suggestion and renamed it to addNSEC3RecordToZone.

 > For both of the above, same for the delete-variant :)

 ack, and updated it accordingly.

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