APQ

From: Brian May (bam_at_snoopy.apana.org.au)
Date: 12/16/04 

Date: Thu, 16 Dec 2004 10:31:49 +1100

Hello,

Here are my suggested changes to APQ (not actually done or tested).

1. Decide on or write a "smart pointer" library. ie. a library that
manages pointers based on a reference count. Obviously the license
must be compatible with the license of APQ.

2. No change to Connection_Type or Root_Connection_Type.

3. Create new Database_Type. This type should not be
tagged. Applications will use this instead of the
Root_Connection_Type. It has the following data:

* Smart pointer to Root_Connection_Type'Class. This is dynamically
  allocated when the connection is created.

It has the following methods:

  * Connect method takes a string, which is the connection URL. Note:
    Two ways of implementing:

    1. connect is hard-coded to support every possible database, and
       parses the URL itself.

    2. each database is registered in a global list, connect
       determines the most appropriate database based on prefix in URL
       and calls appropriate connect method with URL.

    The second method is more complicated but more flexible. In any
    case, changing this should not require changing the user API.

  * All methods associated with Root_Connection_Type. This does *not*
    include options to set options specific to the database, like user
    name or password. These call the appropriate routine in the
    Root_Connection_Type'Class. Status information should perhaps be
    cached, so it remains constant even after queries (might be more
    appropriate way to handle errors).

  * New_Query takes a *Database_Type* parameter, not a
    Root_Connection_Type parameter. This function constraints a query
    and saves a smart pointer to the Root_Connection_Type contained
    within the Database_Type variable.

  * Debatable: Function that returns smart pointer to
    Root_Connection_Type'Class. This might be required to access
    database specific functions. Ideally it shouldn't be required.

4. Modify Root_Query_Type class:

   New_Query is the only function that takes a *Database_Type*
   parameter.

   The functions that use to require Root_Connection_Type now use the
   smart pointer that was saved instead.

   Why not make the procedures abstract instead of having them raise
   an Is_Abstract? This way the checks can be done at compile time.

   Execute already returns exception if not connected.

   Add methods for obtaining and clearing status information. This
   should be cached so if you execute two separate queries (in two
   separate variables) on the same database, you will get two status
   messages saved.

I hope this helps explain what I said earlier... I believe this solves
a number of concerns with the existing system in one go.

The major difference is that I have created a new Database_Type class,
which allows the Connection_Type to be shared in a safe manner between
the user Database_Type and the user Query_Type classes.

This would involve making incompatible changes to Root_Query_Type. It
might be possible to avoid this, not sure if it would be worth the
effort.

Comments? 

-- 
Brian May <bam@snoopy.apana.org.au>