BIND 10 #2108: redefine in-memory zone load()

[BIND 10 Development]

#2108: redefine in-memory zone load()
-------------------------------------+-------------------------------------
                   Reporter:         |                 Owner:  muks
  jinmei                             |                Status:  reviewing
                       Type:  task   |             Milestone:
                   Priority:         |  Sprint-20120918
  medium                             |            Resolution:
                  Component:  data   |             Sensitive:  0
  source                             |           Sub-Project:  DNS
                   Keywords:         |  Estimated Difficulty:  6
            Defect Severity:  N/A    |           Total Hours:  0
Feature Depending on Ticket:         |
  scalable inmemory                  |
        Add Hours to Ticket:  0      |
                  Internal?:  0      |
-------------------------------------+-------------------------------------
Changes (by jelte):

 * owner:  UnAssigned => muks


Comment:

 zone_table.[h|cc]:

 in setZoneData(), should we differentiate between whether a node was not
 found and whether a node was found, but its old data was empty? (behaviour
 is different but no way to tell from the caller's side)

 memory_messages.mes is not sorted (we have a tool for that:
 tools/reorder_message_file.py)

 memory_client.h:

 - the comment "(but there's a plan to use database backends as a source of
 the in memory data)" seems out of date :)
 - for some reason, the getFileName() documentation somehow made it seem as
 if the Client can only load and represent one zone. I don't think the
 comment needs to change fundamentally, but I would probably add something
 like 'of the zone with the given Name' somewhere in the beginning, and
 change tha last part from 'hasn't loaded any file' to 'has not loaded the
 zone' (do we expect this to be a normal scenario btw? perhaps a NoSuchZone
 exception could also be in order, esp. if setZoneData() would have
 something like that as well)
 - typo at line 225: 'peristently'
 - Personally, I don't think the pimpl pattern is needed here (and in fact
 i removed it in my new zonefinder implementation), but no extremely strong
 opinion atm

 On a slightly higher level, is findZone2() needed because we don't (yet)
 have the ZoneFinder? (i.e. 2109) I'm not sure why it is needed otherwise
 (i.e. when all are merged we *should* be able to use the normal
 findZone(), as i think that should create and return a zondefinder then)

 Oh, and cppcheck reports a number of errors, btw :)

 memory_client.cc:

 - ZoneData has a getOriginNode(), in theory this could be passed to the
 MemoryIterator constructor (instead of doing a find() there)
 - addFromLoad comment says it throws, but it actually aborts

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