Re: Ada DB bindings and APQ

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

On Tue, 14 Dec 2004 18:29:16 +0000 (UTC), Georg Bauhaus wrote:

> Dmitry A. Kazakov <mailbox@dmitry-kazakov.de> wrote:
>: On Tue, 14 Dec 2004 02:25:22 -0500, Warren W. Gay VE3WWG wrote:
>: Yep, the first error one gets: lpq not found. libpq.a is not distributed
>: with GNAT. This might become a problem in the future.
> 
> I'm not at all surprised that when I use a binding but not the bound
> thing, I'll get an error.

Does your OS complain about all devices you could potentially attach via
USB?

>: Yes, but from user's perspective, at least one query per connection is
>: always necessary. In some cases the user will need more, but not so often.
> 
> I doubt this very much. Indeed, we have a server type application
> that does not work at all without a connection pool, because performance
> is affected rather drastically when you control connections.

OK, but this does not contradict my point.

> This is at least true for the DB systems we have had a chance to try.
> 
> If then you want one physical connection to play the part of a
> "reusable" connection that is not in the way of programmers,
> then why do you need one at all in the abstraction?
> For example, how about ticket based query authentication?

Sounds as an implementation detail to me, elaborate.

>: I do not see much sense in all that levels of types exposed to the user.
> 
> As a user, I agree that a DWIM DB abstraction is wonderful.
> It just isn't practical when using current database technology :-)

I still do not see any real advantage in separating query and connection.
It would be no problem to have both multiple physical connections and
multiple physical queries without exposing them.

Maybe within the hierarchy: transaction / server, it makes sense to
distinguish both, but separating query /connection makes no sense to me. 

>: Internally of course. This could be necessary for "light-weight" connection
>: cloning.
>: 
>: Handle --> Query_Object --> Connection_Object
>: 
>: 1. Handle copy (+1 reference count of Query_Object)
>: 2. Light-weight copy: creates new query (+1 reference count of connection)
>: 3. Heavy-weight copy: creates a new query and a new connection
> 
> This starts looking like optimazation techniques used in current
> database systems.

So, you agree? (:-))

>: My case is much simpler. The application
>: starts, it checks if DB exists, if not, it creates that empty.
>: I believe,
>: this is about 80% of needs for small applications.
> 
> Aha! So your goal is to have a convenient abstraction for
> a specific kind of data storage in small applications?

Sure. For a large application, DB will almost certainly be fixed in the
requirements. Forget it. But!

Do it [right] for small things first. Then you will see how quickly it will
eat that large players. PCs vs workstations (or cockroaches vs humans, if
you want (:-)), lessons to learn!

>: Anyway, there should be a uniform way of putting values into requests
>: separated from SQL-keywords, and, probably, names of tables, of columns
>: etc.
> 
> This again sounds like a newly designed Ada-interface based OO data storage
> system for Ada programs...

That's not OO, yet. It is rather typed vs untyped.

> Go ahead :)

Let's see (:-))

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