BIND 10 #1061: introduce DatabaseClient (or DatabaseDataSourceClient)

[BIND 10 Development]

#1061: introduce DatabaseClient (or DatabaseDataSourceClient)
-------------------------------------+-------------------------------------
                   Reporter:         |                 Owner:  stephen
  jinmei                             |                Status:  reviewing
                       Type:  task   |             Milestone:
                   Priority:  major  |  Sprint-20110816
                  Component:  data   |            Resolution:
  source                             |             Sensitive:  0
                   Keywords:         |           Sub-Project:  DNS
            Defect Severity:  N/A    |  Estimated Difficulty:  5.0
Feature Depending on Ticket:         |           Total Hours:  0
        Add Hours to Ticket:  0      |
                  Internal?:  0      |
-------------------------------------+-------------------------------------

Comment (by jinmei):

 Replying to [comment:8 vorner]:

 Not intending to steal the review, but I thought I might be able to
 clarify some points in the discussion, so...

 > > Exception information should be described using the \exception tag.
 >
 > I have nothing against it, but it doesn't seem we use that convention
 much.

 That would be helpful if and when we introduce the Python script that
 converts C++ doxygen to a template Python docstring (for the
 corresponding C++ binding).  (There's a ticket for this: #933).

 > > > I don't think the two-phase initialization of constructor and
 calling init is needed, so I put the parameters to the constructor
 directly. If the configuration is changed, a new connection can be created
 and the old one destroyed. I believe it is simpler this way, but I don't
 know what was the original idea here.
 > > I would guess to avoid an exception being thrown from the constructor.
 >
 > What is wrong with that?

 I don't remember why the original code adopted the two-phase
 initialization (constructor and init()), but at least for the design
 concept of DataSourceClient, I suspect we don't need the phased
 initialization.  If there's a need for reinitializing it, we'd
 probably reconstruct a new client.

 And, as far as I can see, there should be no problem in having the
 possibility of throwing an exception from constructor.

 > > Regarding the configuration change, there is a comment in the
 !DatabaseClient header to the effect that objects returned hold references
 to the connection.  If there is such an outstanding object when a
 configuration change comes it, destroying the old connection and creating
 a new one could lead to problems.
 >
 > I believe the object should be short-lived, only for one query. At last
 the current usage indicates it. So, if it is reconfigured between queries,
 it shouldn't be problem. But currently, with the shared pointer, it
 shouldn't have the problem any more anyway.

 Is it about DataSourceClient?  If so, no, the intent was that an
 application will keep a client as long as possible (for performance
 reasons).  ZoneFinder objects are expected to be short lived.

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