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