Re: Ada DB bindings and APQ

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

On Sat, 18 Dec 2004 19:53:51 -0500, Warren W. Gay VE3WWG wrote:

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

These connections are between implementation objects. There is no reason to
expose these details to the end user.

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

It is not their approach. At least in MFC. Either because of C++ object
construction model deficiency, or just in order to keep users in awe, but
the result is that anything has Init().

As a user I don't want to control anything. I just want to use it. Only
when it first works, and there are problems with how it works, then maybe,
but unlikely, I would attune it a bit.

The major goal of any bindings is to maintain complexity.

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

Exactly, because not every device would allow it. It would be a bad design
to allow rewind that throws Use_Error. A proper design would be to derive a
class of files which can be rewound from the base class of files.

> You would have to destruct it and recreate it.

Yes, because the file was a socket!

> An object goes through states, sometimes many of them. I see nothing
> half baked about being connected or not.

Do not forget separation of implementation and interface. There are logical
and physical states, there are interface and implementation objects. They
need *not* to be same. You are trying to throw everything in one cauldron.

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

These states are of no user interest. I do not need an unconnected
connection. Really, it is like inedible food.

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

If you compare the time required to connect with the time required to
initialize an interface object you will find that the latter is negligible. 

If you mean a physical communication object, then again it is not user's
responsibility. Normally, it is OS which maintains a pool file descriptors.
Because they are OS's resources. It would be wrong to require from an Ada
application to interfere there.

Let that be an issue, then most probably it will highly depend on the
target DB type. So the user will have no opportunity to influence it
anyway. It is the responsibility of bindings to internally provide pools of
objects expensive to create.

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

In the interface it is 1 to 1. Internally it might be any, why should I
care?

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

Alas, but they are not portable.

> That way I don't have to force the user to use types that I dream up.

[ Ada 2005 will finally have multiple inheritance restricted to interfaces.
That will solve the problem without ugly generics. ]

Look, you describe the interface of a DB type and user have to implement
it. Note that it is not you, who forces the user, but a very real thing,
the DB. There *must* be a mapping between DB and user types. Your "dreamed
up" types just embody that mapping.

User-defined type conversions might do it very easy and elegant, but that
is another story.

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