BIND 10 #1179: python interface for data source

[BIND 10 Development]

#1179: python interface for data source
-------------------------------------+-------------------------------------
                   Reporter:         |                 Owner:  vorner
  jinmei                             |                Status:  reviewing
                       Type:  task   |             Milestone:
                   Priority:  major  |  Sprint-20110927
                  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:  0      |
                  Internal?:  0      |
-------------------------------------+-------------------------------------
Changes (by jelte):

 * owner:  jelte => vorner


Comment:

 Replying to [comment:10 vorner]:
 > Hello
 >
 > First, I had a failure in the tests:
 > {{{
 > FAIL: test_iterate (__main__.DataSrcClient)
 > ----------------------------------------------------------------------
 > Traceback (most recent call last):
 > }}}
 >
 > This is output after I turned off the truncation of errors. I guess it's
 not guaranteed to be in any order if it is different RRsets. What should
 we do? Test a zone that is not signed? Allow reordering with RRsigs?
 Because this order is implementation dependant and probably even random-
 way-stored-in-DB dependant.
 >

 hmm, possibly the order of the rrsets themselves is undefined too, as
 might be
 the order of the rdatas within rrsets.

 I've made it into a more general way (make a list of rrsets to expect, and
 check them one by one on name, class, type, sorted rdata), instead of
 hoping
 that to_text() returns the same). It does completely skip rdata for RRSIG
 rrsets now; the API won't allow me to recreate rrsig data 'FAKEFAKEFAKE'
 :)

 > Why is this called _log_libdir?
 > {{{
 > loglibdir = os.path.join(base, 'isc/datasrc/.libs')
 > }}}
 >

 changed to datasrclibdir

 > And, it seems, this branch was a huge copy-paste from somewhere. For
 example, this looks as copied from somewhere (the acl module):
 > {{{
 > // The __init__.py file should ensure isc.acl.acl has been loaded by the
 time
 > }}}
 >
 > As well as this (it talks about a generic template for descructor, maybe
 that could be removed, multiple times):
 > {{{#!C++
 > // This is a template of typical code logic of python object destructor.
 > // In many cases you can use it without modification, but check that
 carefully.
 > void
 > DataSourceClient_destroy(s_DataSourceClient* const self) {
 > }}}
 >

 actually, most of it comes out of the 'template-for-python-
 wrappers'-generator
 script. I removed these now irrelevant comments (and a few others i think
 are
 superfluous)


 > Another thing is, I don't mind having the find methods, etc, directly on
 the updater. But the wrappers are nearly identical copies of each other
 and they are not really short. Is there a way to do it in some kind of
 templateish way and share the same code?
 >

 doesn't need to be a template, I made a ZoneFinder_helper function, which
 is
 used in both (put it in a separate namespace, and is not defined in
 headers).
 I did not do the same trick for get_class and get_origin, as that code is
 just
 one call with a bit of exception catching. We could do the same for those
 though.

 > I guess you should go through the semi-auto generated documentation. A
 lot of it talks about stuff that is irrelevant to python, makes no sense
 in python or is just plain wrong. It talks about constructors, classes
 that are not visible from python at all, std.bad_alloct exceptions,
 protected constructors (there's no protected in python), NULL pointers. It
 is also badly formated sometimes (like TodoSome sentence, some parts of
 enums are there twice, sometimes a sentence is missing or there are \n\
 sequences, which might be correct, but they look strange).
 >
 > And I'd like to note, that there are some changes from #1176 (like
 another flag for the find method) and there'll be more from #1177 (more
 status codes from find, extra method on finder). When should these be
 added? Whoever merges first wins and the other one needs to implement
 them?
 >

 I think we can make separate tasks for those. They should be pretty
 small.

 > Otherwise, the code looks quite straight-forward and I like the way the
 return values are converted (createRRClassObject).
 >

 cool, thanks :)

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