BIND 10 #1688: duplicate RR suprression in auth::Query

[BIND 10 Development]

#1688: duplicate RR suprression in auth::Query
-------------------------------------+-------------------------------------
                   Reporter:         |                 Owner:  jinmei
  jinmei                             |                Status:  reviewing
                       Type:  task   |             Milestone:
                   Priority:         |  Sprint-20120403
  medium                             |            Resolution:
                  Component:         |             Sensitive:  0
  b10-auth                           |           Sub-Project:  DNS
                   Keywords:         |  Estimated Difficulty:  5
            Defect Severity:  N/A    |           Total Hours:  0
Feature Depending on Ticket:         |
        Add Hours to Ticket:  0      |
                  Internal?:  0      |
-------------------------------------+-------------------------------------
Changes (by jelte):

 * owner:  jelte => jinmei


Comment:

 I must say I also didn't see the use of an extra class for this; the
 complexity should be the same if we use a local helper method instead of
 direct push_back for the three vectors in the Query class (which would
 only add to the given vector if they are not present in any). The only use
 this has is that now, it can never happen that rrsets are not put in
 answer if they are already present in authority or additional (whereas a
 local checker would result in first-come-first-serve instead of
 prioritizing answer>auth>additional)

 comments on the code itself:

 * ResponseCreator::create(): additionals argument is not a reference
 * new includes in rbnode_rrset_unittests.cc? (<algorithm> and <sstream>, I
 suspect these are leftovers from now-removed code)
 * leftover newline in rbnode_rrset.cc
 * there are new includes in rrset_unittest too (iostream)

 Oh and I suggest the changelog entry does not do 'used-to'; i.e. make it
 something like "b10-auth now filters out duplicate rrsets when building a
 response message" (can still say what it used to do, as long as we
 explicitly say what it does now :))

 For the rest it looks ok

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