BIND 10 #2908: Python wrapper for ZoneTableAccessor and getZoneTableAccessor

[BIND 10 Development]

#2908: Python wrapper for ZoneTableAccessor and getZoneTableAccessor
-------------------------------------+-------------------------------------
            Reporter:  jinmei        |                        Owner:
                Type:  task          |  pselkirk
            Priority:  medium        |                       Status:
           Component:  data source   |  reviewing
            Keywords:                |                    Milestone:
           Sensitive:  0             |  Sprint-20130611
         Sub-Project:  DNS           |                   Resolution:
Estimated Difficulty:  5             |                 CVSS Scoring:
         Total Hours:  0             |              Defect Severity:  N/A
                                     |  Feature Depending on Ticket:
                                     |  shared memory data source
                                     |          Add Hours to Ticket:  0
                                     |                    Internal?:  0
-------------------------------------+-------------------------------------

Comment (by pselkirk):

 Replying to [comment:8 vorner]:

 > '''Interface'''
 >
 > I don't think the python interface needs the explicit methods, like
 `is_last`. I believe the python iteration protocol is enough and these
 methods would only confuse python programmers.

 The `ZoneIterator` wrapper provides `getNextRRset` as well as `__next__`,
 but it's never used outside of the unit test. So that may not have been
 the best model.

 In any case, I don't mind removing the C++ iterator wrappers, and leaving
 just `get_current`.

 > Second, I know the ticket says so, but it seems to be that „zone table“
 sounds already like the container holding zones, so it should be possible
 to iterate directly over it

 Okay, I changed the names back to `get_zone_table_accessor` and
 `get_iterator`. The `DataSourceClient` wrapper provides `get_iterator`, so
 I guess it's not too ugly.

 If you have ideas about how to reduce the layers of abstraction in the
 Python interface, I'd be glad to hear them.

 > Also, the `get_zone_table` takes empty string to signify „whatever you
 want to give me“. It would make some sense to allow None there instead of
 empty string, which would look more the python way.

 Easy enough to add.

 > '''Tests'''
 >
 > Why does this throw? I'm not claiming it should not, it is just unclear
 from the test why it should and it would require a comment.
 > {{{#!python
 >         self.assertRaises(isc.datasrc.Error,
 >                           self.clist.get_zone_table, "", False)
 > }}}

 It throws `NotImplemented` because the `use_cache` argument is false, and
 `getZoneTableAccessor` is only implemented for caching data sources at the
 moment.

 > With the iterator tests, I think it should be tested inside the `for`
 construct too, not only by creating list from it. Also, it should be
 examined what is being returned as the values from the iterator, not only
 that it returns the right number of items.

 Fair enough, I'll see what I can work up.

 > We probably want to test successful `get_zones` with giving name. Only
 unsuccessful and with empty name are tested.

 There's one test that explicitly requests `MasterFiles`.

 Currently, the data source client lists are limited to a single data
 source `MasterFiles` because I haven't done any sqlite3 tests, and the
 python wrapper for `ConfigurableClientList` doesn't allow bogus data
 sources in the configuration.

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