From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00 autolearn=ham autolearn_force=no version=3.4.4 X-Google-Thread: 103376,2843c5eea3415584 X-Google-Attributes: gid103376,public X-Google-Language: ENGLISH,ASCII-7-bit Path: g2news1.google.com!news3.google.com!newshub.sdsu.edu!elnk-nf2-pas!newsfeed.earthlink.net!sjc1.usenetserver.com!news.usenetserver.com!nf3.bellglobal.com!nf1.bellglobal.com!nf2.bellglobal.com!news20.bellglobal.com.POSTED!not-for-mail From: "Warren W. Gay VE3WWG" User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.7.2) Gecko/20040804 Netscape/7.2 (ax) X-Accept-Language: en-us, en MIME-Version: 1.0 Newsgroups: comp.lang.ada Subject: Re: APQ (Connection Cloning) References: <2hju7i5ft73q$.x4md24pt913v.dlg@40tude.net> In-Reply-To: Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit Message-ID: <1TCyd.29237$GK5.1510003@news20.bellglobal.com> Date: Thu, 23 Dec 2004 12:04:02 -0500 NNTP-Posting-Host: 198.96.223.163 X-Complaints-To: abuse@sympatico.ca X-Trace: news20.bellglobal.com 1103821373 198.96.223.163 (Thu, 23 Dec 2004 12:02:53 EST) NNTP-Posting-Date: Thu, 23 Dec 2004 12:02:53 EST Organization: Bell Sympatico Xref: g2news1.google.com comp.lang.ada:7194 Date: 2004-12-23T12:04:02-05:00 List-Id: Brian May wrote: >>>>>>"Dmitry" == Dmitry A Kazakov 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