BIND 10 #2435: implement datasrc version of RRsetCollection

[BIND 10 Development]

#2435: implement datasrc version of RRsetCollection
-------------------------------------+-------------------------------------
            Reporter:  jinmei        |                        Owner:
                Type:  task          |  jinmei
            Priority:  medium        |                       Status:
           Component:  data source   |  reviewing
            Keywords:                |                    Milestone:
           Sensitive:  0             |  Sprint-20130108
         Sub-Project:  DNS           |                   Resolution:
Estimated Difficulty:  4             |                 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):

 '''generic'''

 - shouldn't the copyright year of new files be 2013?

 '''rrset_collection.h'''

 - maybe a matter of taste, but I'd generally like to avoid the
   abbreviation of "DS" to mean "data source".  "DS" is too short and
   could mean anything, and, in particular, it can be easily confused
   with the delegation signer in the context of DNS:
 {{{#!cpp
     class DsIter : public RRsetCollectionBase::Iter {
 }}}
 - the relationship between the lifetimes of the updater and the
   collection should be documented.
 - should we bother to even define `DsIter`?  If both getBeginning()
   and getEnd() just throw, this class can never even be instantiated
   in practice.

 '''rrset_collection.cc'''

 - I wouldn't leave the TODO open.  Although it wouldn't be critical
   for our intended usage in practice, implementing it shouldn't be
   difficult.  e.g. we can pass the RR class on construction as the
   user of the collection should know it; alternatively, we can check
   rrset->getClass() for the return value of find() and if doesn't
   match return NULL instead.
 - It doesn't seem to handle other minor cases correctly: what if the
   finder returns DNAME?  Or CNAME?  Or delegation?  And any other
   possible cases?  What if the wildcard flag is set even if you
   specify NO_WILDCARD?

 '''database_unittest'''

 - Why does it only test it with SQLite3?  In general, our primary
   intent in this test .cc is to use the mock.
 - It doesn't test if no-wildcard and glue-ok are really effective.
 - It doesn't test DNAME, CNAME, etc, cases (see the comments on the
   implementation)

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