BIND 10 #1198: Split DatabaseClient::Finder::find

[BIND 10 Development]

#1198: Split DatabaseClient::Finder::find
-------------------------------------+-------------------------------------
                   Reporter:         |                 Owner:  jinmei
  vorner                             |                Status:  reviewing
                       Type:         |             Milestone:
  enhancement                        |  Sprint-20111206
                   Priority:  minor  |            Resolution:
                  Component:  data   |             Sensitive:  0
  source                             |           Sub-Project:  DNS
                   Keywords:         |  Estimated Difficulty:  4
            Defect Severity:  High   |           Total Hours:  0
Feature Depending on Ticket:         |
        Add Hours to Ticket:  0      |
                  Internal?:  0      |
-------------------------------------+-------------------------------------
Changes (by stephen):

 * owner:  stephen => jinmei


Comment:

 Additional comments (to be read in conjunction with those above):

 >> If you agree with the general intent of my proposal, please also note
 that you'll need to update the documentation of some of the methods you
 introduced in the branch and provide document for newer methods and new
 log messages.
 > What would really help is to have a general description of the algorithm
 somewhere. I found it difficult to follow the logic in some places - I was
 reverse engineering the documentation from the code.
 I've now done that and added more detailed comments to the code.  At this
 point I'm hoping that the reading the comments + code should allow someone
 to understand what's happing without too much effort on their part.

 >> (In case we agree on the further refactoring idea) I'd also like to
 simplify the for loop of findWildcardMatch() using the same/similar
 technique as find(). But this method may not be so unreadable in its
 current form, so I didn't touch it.
 > I'll have a look at it.
 With the added comments I think it's now understandable enough without
 further decomposition into separate functions.

 >> (Although this may not actually be a topic of this refactoring task) in
 findWildcardMatch(), isn't it possible (thought probably rare or due to a
 pathological database) that getting NSEC fails here?
 It could do.  I thought about testing for it here, but doesn't that fall
 into the more general case of requesting DNSSEC data from a zone we
 believe to be signed and not finding it?  I'd prefer to put this into a
 separate ticket.

 Two other things:
 * I've added a small utility to the tools directory to process message
 files and put them in alphabetical order of message ID.  The message file
 has been run through this.
 * There are four TODOs in database.cc: three are requesting clarification
 of the algorithm (in particular, reasons why it does/does not do
 something).  The fourth - line 792 - proposes alternate processing at a
 given condition.  Comments/thoughts requested.

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