BIND 10 #1576: implement ZoneFinder::findNSEC3 in in-memory data source

[BIND 10 Development]

#1576: implement ZoneFinder::findNSEC3 in in-memory data source
-------------------------------------+-------------------------------------
                   Reporter:         |                 Owner:  jinmei
  jinmei                             |                Status:  reviewing
                       Type:  task   |             Milestone:
                   Priority:  major  |  Sprint-20120221
                  Component:  data   |            Resolution:
  source                             |             Sensitive:  0
                   Keywords:         |           Sub-Project:  DNS
            Defect Severity:  N/A    |  Estimated Difficulty:  6
Feature Depending on Ticket:         |           Total Hours:  0
        Add Hours to Ticket:  0      |
                  Internal?:  0      |
-------------------------------------+-------------------------------------
Changes (by vorner):

 * owner:  vorner => jinmei


Comment:

 Hello

 First, it fails to compile on my system:
 {{{
 rc_unittest.cc:313:22: error: declaration of
 ‘<unnamed>::TestNSEC3HashCreator::TestNSEC3Hash::NSEC3HashMap
 <unnamed>::TestNSEC3HashCreator::TestNSEC3Hash::map’
 /usr/lib/gcc/x86_64-pc-linux-gnu/4.5.3/include/g++-v4/bits/stl_map.h:87:5:
 error: changes meaning of ‘map’ from ‘class std::map<isc::dns::Name,
 std::basic_string<char> >’
 }}}

 I'm not sure I like the NSAC3HashCreator approach. If it is for testing
 only, it looks like an overkill, introducing yet another abstract base
 class, which is 2 already for the simple thing of calculating a hash. If
 it was to provide some flexibility, it would be OK, but it doesn't. If you
 replace the creator for some experimental hash algorithm, you lose the old
 one. Not to say that this wouldn't work if two people provided two plugins
 for two different algorithms. Would it be possible to keep a map from
 algorithm to creator? Then the tests could use some non-existent protocol
 for the fake hashes and coexist peacefully with the rest and it would
 provide the flexibility (eg. be able to add as mane creator as there are
 algorithms).

 Is there any reason why the destructor of InMemoryZoneFinderTest is
 virtual?

 This comment looks odd in this context. Why is it `EXPECT_THROW` if the
 result is guaranteed?
 {{{#!c++
     // Unless NSEC3 for apex isn't added the result in the recursive mode
     // is guaranteed.
     const string ns1_nsec3_text = string(ns1_hash) + ".example.org." +
         string(nsec3_common);
     EXPECT_EQ(result::SUCCESS,
 zone_finder_.add(textToRRset(ns1_nsec3_text)));
     EXPECT_THROW(zone_finder_.findNSEC3(Name("www.example.org"), true),
                  DataSourceError);
 }}}

 Thanks

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