BIND 10 #1066: support wildcard matching in DatabaseZoneHandle::find().

[BIND 10 Development]

#1066: support wildcard matching in DatabaseZoneHandle::find().
-------------------------------------+-------------------------------------
                   Reporter:         |                 Owner:  vorner
  jinmei                             |                Status:  reviewing
                       Type:  task   |             Milestone:
                   Priority:  major  |  Sprint-20110830
                  Component:  data   |            Resolution:
  source                             |             Sensitive:  0
                   Keywords:         |           Sub-Project:  DNS
            Defect Severity:  N/A    |  Estimated Difficulty:  5.0
Feature Depending on Ticket:         |           Total Hours:  0
        Add Hours to Ticket:  0      |
                  Internal?:  0      |
-------------------------------------+-------------------------------------
Changes (by jelte):

 * owner:  jelte => vorner


Comment:

 I have taken the liberty to add one test case (direct query for
 cancel.here.wild.example.org/AAAA) and fixed one typo in a comment

 generally; I think the code looks ok (i predict lots of conflicts again,
 btw, searchForRecords() is gone :p), but the find() method is getting
 extremely long now (almost 200 lines) while it structurally looks like it
 can be split up quite well. Lot's of lines are log calls but still :)
 Though I understand if we want to get the functionality complete and then
 move some code around (also to try and minimize conflicts), I'll leave it
 up to you, but we should make a ticket then.

 Regarding the GLUE_OK case; it's one part interpretation of 'glue is ok',
 and one part 'just' a matter of how we want to handle the response (cause
 in effect it shouldn't matter that much). I see no objections to making
 'GLUE_OK' mean 'ignore zone cuts completely' but we should then probably
 rename it (since below-zone-cut-data is not always glue, but i don't think
 that's taken into account now either). If there is no use-case for the
 current behaviour it might indeed be more logical to have an ignore-zone-
 cut option.

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