Re: APQ (Connection Cloning)

["Warren W. Gay VE3WWG" <ve3wwg@NoSPAM.cogeco.ca>]

Brian May wrote:
>>>>>>"Dmitry" == Dmitry A Kazakov <mailbox@dmitry-kazakov.de> writes:
...
> Can somebody please let me know what applications a cloning function
> has? I frequently hear of such functions, but rarely (if ever) needed
> to use one.

The "cloning" calls are for the most part, convenience calls. You can
accomplish the same thing without them, though it is IMHO very inconvenient
and perhaps error prone (because different databases require different
parameters). But if a programmer must do something often enough, then
I believe that the "package" should make it easier and less error
prone for the application writer.

One problem that APQ's API has, is that I rolled the "environment"
into the Connection_Type object (this was discussed earlier). The consequence
of that is that when you need a second database connection (more on that
later), without a clone call, you need to supply all of the same database
connection parameters to create a new connection (userid, password, port
etc.) This is even more painful when you are trying to implement
database portable code, because then you also must concern yourself
with which parameters that must be carried over.

For this reason, it makes sense for APQ to 'care' about this, because
it has intimate knowledge of what has been used for the connection.
So cloning a connection becomes easier for APQ to do, than it would
be for the application writer to do it, without APQ's help.
The programmer simply wants another connection "like that one".

Why a second database connection? The reasons vary, but the following
reasons come to mind right away:

  - If you are maintaining a pool of connections to the same database
    (webserver). Even if you start with a fixed set of connections,
    a server may want to add to the pool as demand increases.

  - Client library limitations: most operations can share the same
    connection, but there are probably some cases where this cannot
    be done (I believe for example, you can only have one active
    transaction going on one connection).

  - You may want to restrict trace (debug) SQL operations, when
    debugging a difficult problem. To reduce the amount of trace
    capture, a cloned connection without tracing may be useful.
    In this case, you would revert back to a single connection
    once the debugging was successfully completed.

This "need" would largely disappear if the database userid, password
etc. was taken out of the Connection_Type and put into a 3rd
object Environment_Type instead. I know Dimitry disagrees with the
yet another object approach, but I believe this is the right
thing to do (TM). In his favour however, I do like the internal
smart pointer idea, to guarantee that essential objects
(connection and environment) do not go out of scope prematurely.

Once the connection "parameters" were placed into their own
Environment_Type object, then multiple Connection_Type objects
can be supplied with a common Environment_Type object instead,
and no "cloning" primitives would be required.

Some of the earlier discussion around internal smart pointers
to these objects starts to make a stronger case as you add yet
another object to the mix. Internally, the Connection_Type object
should hold a smart pointer back to the Environment_Object, and
of course, Query_Type objects would hold a smart pointer back
to the Connection_Type object. Then as has been suggested, you
could drop the Connection_Type object argument in some of the
calls like Execute() et al. The following shows how the objects
are related:

  Environment <- Connection <- Query
      1       <-     N
                     1      <-   N

-- 
Warren W. Gay VE3WWG
http://home.cogeco.ca/~ve3wwg