Re: Ada DB bindings and APQ

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

Dmitry A. Kazakov wrote:
> 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:
...
>>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

Again, they have different data items, states and methods. Again,
you have a 1 to many relationship between environment and
connections!

>>  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. 

 From a user's perspective, you want "control". You are espousing
a Microsoft approach where you take control away from the caller,
and instead tie connection with construction. This is not very
flexible.

> 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:

Look, it has nothing to do with Ada or "half baked" objects ("baked"
is what I think you meant). It is all about control. If we took your
view, you would never allow a Rewind operation on a file. You would
have to destruct it and recreate it.

An object goes through states, sometimes many of them. I see nothing
half baked about being connected or not. What IS half baked about it
is that it combines Environment & connection! By putting them in
one object, I multiply the number of states and methods for a
combined object.

>    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

This is one approach, but there are times when it is much better
(efficiency is one way it can be "better") to manage it by state,
rather than tie it to object construction. For example, in a
web server you may want to manage a pool of connections. Yes,
you can manage it by creation/destruction, but this is more
expensive than connecting/disconnecting a database.

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

There is a 1 to many relationship between connections and queries!

>>  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.

Naw. I prefer to use Ada streams for Blob I/O. That way I don't
have to force the user to use types that I dream up.

>>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'm sorry, but yuk.

>>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! (:-))

:)

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