BIND 10 #1331: Extend the ZoneUpdater class to support adding diffs

[BIND 10 Development]

#1331: Extend the ZoneUpdater class to support adding diffs
-------------------------------------+-------------------------------------
                   Reporter:         |                 Owner:  jinmei
  jinmei                             |                Status:  reviewing
                       Type:  task   |             Milestone:
                   Priority:  major  |  Sprint-20111122
                  Component:  data   |            Resolution:
  source                             |             Sensitive:  0
                   Keywords:         |           Sub-Project:  DNS
            Defect Severity:  N/A    |  Estimated Difficulty:  4
Feature Depending on Ticket:         |           Total Hours:  0
        Add Hours to Ticket:         |
                  Internal?:  0      |
-------------------------------------+-------------------------------------

Comment (by jinmei):

 Replying to [comment:15 vorner]:

 > > - In zone.h, is this "...look like an IXFR"?
 > > {{{
 > >     /// If journaling was requested when getting this updater, it
 might reject
 > >     /// to add the RRset if the squence doesn't look like and IXFR
 (see
 > > }}}
 > >   (didn't notice that in the previous review).  Also, I guess we
 should now
 > >   change "might reject" to "will reject".  Applies to both addRRset()
 and
 > >   deleteRRset().
 >
 > Hmm, but then if someone would like to implement their own data source
 client, they would be required to check it. I'd like to allow the
 flexibility in not requiring the check. Any idea how to word it so it is
 clear the sequence must be IXFR like, but the check is optional?

 If the sequence requirement is a must, what's the point of the
 "flexibility" of not doing the check?  That just seems to be laziness
 that naively trusts the application does the right thing.

 If you are thinking about future extension of a smarter data source
 (which we discussed in this ticket) with a specific application that
 selectively uses that kind of data sources, we'll of course loosen the
 check requirement at that point.  But until/unless we have a real need
 for it I'd rather keep the check tighter so that bugs in the
 application can be detected more easily and sooner.

 > > I don't necessarily think it should; I just wondered.  But the reason
 > > about this is different from other semantics errors like duplicate
 > > CNAME.  In the case of multiple SOA RRs, it would break the specific
 > > assumption of this method, that is, the resulting sequence is in the
 > > IXFR order.
 >
 > It is harder to create a SOA with multiple RRs than it is to mix the
 order. So I'd say we leave this check for now, it doesn't seem to bring
 any real advantage.
 >
 > > Finally, in case you forget it, please check with Jeremy whether we
 > > want to have a changelog entry.

 Okay.

 > He says he would like one. So, something like this?
 >
 > {{{
 > [func]
 > The database data sources can now store diffs when updating the data.
 > }}}

 We actually also extend the top level interface.  I'd mention that,
 e.g.:
 {{{
 317.?   [func]
         datasrc: the getUpdater (and get_updater for python) method of
         DataSourceClient supports an optional 'journaling' parameter to
         indicate the generated updater to store diffs.  The database based
         derived class implements this extension.
 }}}

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