BIND 10 #2877: slow updates to SQLite3 data source

[BIND 10 Development]

#2877: slow updates to SQLite3 data source
-------------------------------------+-------------------------------------
            Reporter:  jinmei        |                        Owner:
                Type:  defect        |  jinmei
            Priority:  very high     |                       Status:
           Component:  data source   |  reviewing
            Keywords:                |                    Milestone:
           Sensitive:  0             |  Sprint-20130423
         Sub-Project:  DNS           |                   Resolution:
Estimated Difficulty:  3             |                 CVSS Scoring:
         Total Hours:  0             |              Defect Severity:  N/A
                                     |  Feature Depending on Ticket:
                                     |          Add Hours to Ticket:  0
                                     |                    Internal?:  0
-------------------------------------+-------------------------------------

Comment (by jinmei):

 Replying to [comment:6 vorner]:
 > It should be ready for review. I applied the patches from the mailing
 list and added some documentation and descriptions for the log messages.
 >
 > We might want to have a changelog message (I'm listing jinmei as the
 author, since he wrote the real patches and found the cause):
 > {{{
 > [bug] jinmei
 > IXFR and DDNS Updates to the sqlite3 database are no longer so slow on
 large
 > zones as they were before.
 > }}}
 >
 > I believe DDNS would have been hit by this too, so it is listed there.

 I'd describe some more details.  Suggestion:
 {{{
 599.?   [bug]*          jinmei(, vorner?)
         The "delete record" interface of the database based data source
         was extended do that the parameter includes reversed name in
         addition to the actual name.  This may help the underlying
         accessor implementation if reversed names are more convenient
         for the delete operation.  This was the case for the SQLite3
         accessor implementation, and it now performs delete operations
         much faster.  At a higher level, this means IXFR and DDNS Updates
         to the sqlite3 database are no longer so slow on large zones as
         they were before.
         (Trac #2877, git TBD)
 }}}

 as for the "credit", I think any developer that made non trivial
 contribution to the task (in this case, it's you) deserves it, but I'd
 leave it to you.

 Regarding the branch:

 - I think we need some more explanation of why we provide DEL_RNAME in
   documentation.  I've committed my proposed text.
 - I wonder whether we should now make `DeleteRecordParams` non-NSEC3
   records only, just like we separate `AddRecordColumns` and
   `AddNSEC3RecordColumns`.  It's a tradeoff between reducing the
   amount of code and disadvantages of overloading (conceptual
   confusion, need for additional tweak in the accessor side), but at
   this point I guess the latter outweighs the former.  If we keep
   overloading, we'll at least need what's in RNAME for NSEC3 and
   what's accessor should do with it.  I'd also guess we'd rather
   specify an empty string in RNAME for the NSEC3 case.

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