BIND 10 #1483: "findAll" method for ZoneFinder

[BIND 10 Development]

#1483: "findAll" method for ZoneFinder
-------------------------------------+-------------------------------------
            Reporter:  jinmei        |                        Owner:
                Type:  task          |                       Status:  new
            Priority:  critical      |                    Milestone:  Next-
           Component:  data source   |  Sprint-Proposed
           Sensitive:  0             |                     Keywords:
         Sub-Project:  DNS           |              Defect Severity:  N/A
Estimated Difficulty:  0             |  Feature Depending on Ticket:
         Total Hours:  0             |          Add Hours to Ticket:  0
                                     |                    Internal?:  0
-------------------------------------+-------------------------------------
 We need an interface for getting all types of RRsets of a given name
 from a data source.  One obvious purpose is to handle a type ANY
 query, but as a more immediate topic we'll need this for some specific
 cases of DDNS:
 - so that we can remove all existing RRs of a give name
 - so that we can confirm a prerequisite that is type-agnostic. this
   can be done by other way than the "get all" interface, but "get all"
   can be used for this purpose.  BIND 9 actually uses a similar
   interface for this purpose.

 In the current API, the 'target' parameter of ZoneFinder::find() was
 intended to be used for this purpose, but it's not implemented in the
 database-based data source yet.

 We could complete that part of implementation, but I've personally
 been thinking it's not a clean design:
 - it would cause a not-well-defined situation with qtype != ANY but
   target is non NULL or qtype = ANY but target is NULL.
 - (in the context of type any query) type ANY queries should generally
   be exceptional (in that normal clients won't query for it).  It
   doesn't seem to be a good idea to integrate such rare cases into the
   code for more typical cases both in terms of clarity and
   (eventually) efficiency.

 So, using this opportunity, I'd propose a separate interface and
 deprecate the use of 'target' parameter of find().  The new interface
 would be a separate method of the ZoneFinder class:

 {{{#!c++
 ZoneFinder::Result
 ZoneFinder::findAll(const isc::dns::Name& name,
                     std::vector<ConstRRset>& result_list
                     /*, maybe an "option" parameter */)
 }}}

 This one is similar to find(), but retrieves all RRsets of the given
 name and inserts them to result_list (which would be expected to be
 empty initially).

 For the purpose of DDNS support, we could initially implement it for
 the database-based data sources only and consider support for it on
 the in-memory data source later.  From a quick look we don't seem to
 need an additional primitive at the lowest level (i.e. for
 SQLite3Accessor), so this single ticket would be reasonably small for
 the entire C++ task.  Python binding would be a separate task.

-- 
Ticket URL: <http://bind10.isc.org/ticket/1483>
BIND 10 Development <http://bind10.isc.org>
BIND 10 Development