Re: Ada DB bindings and APQ

["Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de>]

On Sat, 18 Dec 2004 15:36:15 -0500, Warren W. Gay VE3WWG wrote:

> Dmitry A. Kazakov wrote:
> 
>> On Wed, 15 Dec 2004 21:53:11 -0500, Warren W. Gay VE3WWG wrote:
>>>Dmitry A. Kazakov wrote:
>>>>On Tue, 14 Dec 2004 23:05:17 -0500, Warren W. Gay VE3WWG wrote:
>>>>>Dmitry A. Kazakov wrote:
>>>>>>Connection could be just a handle to some dynamic-scope connection object
>>>>>>with reference counting. This will solve both the problem of above and
>>>>>>still allow cloning connections.
>>>>>
>>>>>I didn't like the use of handles for database objects. I purposely
>>>>>stuck to using controlled objects, so that they can go out of
>>>>>scope gracefully, be finalized (perhaps committed or rolled back)
>>>>>and then destructed. Handles, like open Ada File_Types, never
>>>>>get that maintenance.
>>>>
>>>>Let's make them derived from Ada.Finalization.Controlled. 
>>>
>>>What's the point of that? Why not use the actual object? It
>>>seems like unnecessary indirection and complexity - what
>>>problem are you trying to solve with handles?
>> 
>> Dynamic scopes. If user creates these objects on the stack then [s]he is
>> responsible for doing it in a proper order. The only way Ada might help
>> here is to use access discriminants, then Ada accessibility rules will do
>> the work.
> 
> Well, I think it is normal to do a lot of things in the "proper
> order" ;-)
> 
> If at the main program level, you connect to the database with
> the Connection_Type (which is the normal practice), and then
> create Query_Type object(s) upon demand within the deeper reaches
> of your application, there is plenty of natural "separation".
> Both object types are already derived from Ada.Finalization.Controlled,
> BTW.

Then you should have no problems with having handles to them. Note that
this by no means would prevent users from using underlying objects directly
if they want.

>>>Here is food for thought ;-) -- if Sybase and other databases implement
>>>their interface with 2-3 different classes of objects, why is the
>>>APQ design so wrong to do something similar?
>> 
>> Sybase interface is a low-level one. If there were an interface to some
>> RISC processor, then probably it would have objects for registers, cache
>> levels etc. It would be very exciting, but annoying for an Ada programmer.
> 
> I don't see how a RISC processor interface applies to the discussion
> at hand. The database client "interface" from an object perspective
> boils down to about 4 generalized objects:
> 
>   1. Environment (userid, passwords, ports, address, hostname etc.)

You can get all that from a connection object

>   2. The connection (methods like connect, disconnect, am I connected)

Why should I connect, disconnect etc. From user's perspective, when I
create an object it should be usable, immediately. Introducing Connect, you
add complexity and various sources of errors. I can understand where
Connect comes from: Ada has no proper constructors with parameters for
limited objects. This is the reason for handles (they are non-limited). But
your objects are not limited, so there is no reason for creating
half-backed objects:

   type Root_Connection_Type (<>) is abstract ...;
      -- Always properly constructed
   function Connect (...) return Root_Connection_Type is abstract;
      -- The only way to create it is this constructor
private
   type Root_Connection_Type is abstract ...;

>   3. The query

Because Connection has no methods except for a construction function, it
can be merged with query

>   4. Blobs

Yes. This is a different thing. One will probably need a common base for
all types on Ada side with can be stored in DB. Blobs is just on of them.
Presumably there also should be DB_Integer, DB_String, DB_Bounded_String
etc.

> If you look at all of these components, they all have their own
> pieces of data, states and methods. In OO design you try to
> subdivide the problem in sensible ways.
> 
> You actually make the API more difficult, if you roll everything
> into one object (I was tempted to call it a blob). Because if I
> am defining an application, then I'd probably only define one
> environment object for each database used (unless I was logging
> in with multiple userids). Normally, I'd only use one database
> connection, but if I were to use more (maybe for performance
> in a server), then they would all share the same environment
> (the parameters are in common). If instead each connection (as
> I have it now) holds the environment, they I have to do extra
> fussing to make sure that I clone all of that environment for
> the new connection.

Oh, that's no problem in my view:

   type Database_Type is abstract ...

   function Connect (...)
      return Database_Type is abstract ;
      -- Creates new connection (and new query)

   function Shared_Session (DB : Database_Type)
      return Database_Type is abstract;
      -- Creates new query, connection is shared

   function New_Session (DB : Database_Type)
      return Database_Type is abstract;
      -- Creates new connection and new query for it

> I regret not having
> separated the environment from the connection, because
> they both serve different purposes and state also.

No reason for regrets, I found it rather refreshing after ugly ODBC! (:-))

>> It is easy. MySQL implementation does know how to properly encode values.
>> But if you think that it is not easy, then it is even more so unfair to
>> push that to poor users! (:-))
> 
> I think you missed the point: Its not hard to make the mechanism work,
> but it is harder to please everyone, and in all of its variations. One of the
> things about libraries and bindings, is that they should not be dictating
> policy. They should simply be there to let the users accomplish their
> goals, but they shouldn't dictate the choices made (on the database side
> for example). The user of APQ may not have a choice in data types being
> used, since the database may prexist, be owned by someone else, etc. etc.

No matter, even if the DB exists, there is still only one valid way to
encode, say, floating point number or string literal. It does not help to
be able to send a garbage only to get SQL_Error in return.

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de