BIND 10 #2539: implement InMemoryClient iterator getSOA()

BIND 10 Development do-not-reply at isc.org
Mon Jan 27 07:11:55 UTC 2014


#2539: implement InMemoryClient iterator getSOA()
-------------------------------------+-------------------------------------
            Reporter:  vorner        |                        Owner:  muks
                Type:  task          |                       Status:
            Priority:  medium        |  reviewing
           Component:  data source   |                    Milestone:
            Keywords:                |  Sprint-20131015
           Sensitive:  0             |                   Resolution:
         Sub-Project:  DNS           |                 CVSS Scoring:
Estimated Difficulty:  3             |              Defect Severity:  N/A
         Total Hours:  0             |  Feature Depending on Ticket:
                                     |          Add Hours to Ticket:  0
                                     |                    Internal?:  0
-------------------------------------+-------------------------------------
Changes (by kean):

 * owner:  kean => muks


Comment:

 Replying to [comment:6 muks]:
 > Is there a use-case for this `getSOA()` optimization?
 As I said in the review, no, I do *NOT*. It was a question, along with a
 commit framing the question.

 > It would also break the "identical" guarantee of
 `ZoneIterator::getSOA()` (though we assume the underlying data source must
 not change during iterator use).
 How would it do that? It returns the same `soa_` each time it is called.

 > But just in case this is required, can you point out a place where
 `getSOA()` needs to be called multiple times?
 Again, no I can not, as stated in the review. However, I do try in general
 to write things not for as their usage is today, but for what it might be
 in the future (I believe some call that "defensive coding").

 Also there is something to be said for consistency. database.cc's
 implementation of getSOA() does it my way. There may be reasons for that
 that I am missing, but is there any reason they should be different?

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


More information about the bind10-tickets mailing list