Re: Windows Ada database support.

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

On Tue, 30 Nov 2004 21:10:11 +0000 (UTC), Georg Bauhaus wrote:

> Dmitry A. Kazakov <mailbox@dmitry-kazakov.de> wrote:
>: On Tue, 30 Nov 2004 16:07:06 +0000 (UTC), Georg Bauhaus wrote:
>: 
>:> Dmitry A. Kazakov <mailbox@dmitry-kazakov.de> wrote:
>:>: On Mon, 29 Nov 2004 22:05:50 +0000 (UTC), Georg Bauhaus wrote:
>:>:>:>   See also Frank Piron's comment about implicit cursors in
>:>:>:> PL/SQL.
>:>:> 
>:>:> Wrong abstractions in PL/SQL too?
>:>: 
>:>: Is in your opinion PL/SQL better than Ada?
>:> 
>:> PL/SQL has a specific purpose, and a rich set of facilities for handling
>:> relations.
>: 
>: 1. Why relations should be handled?
>: 2. Why Ada cannot handle them?
> 
> One reaon that Ada, as is, cannot handle the same set of problems
> as PL/SQL with the same ease is, I think, that PL/SQL is a programming
> language with built in support for database operations. You'd have to
> define at least everything that has been defined (or not) for PL/SQL,
> taking into account all Ada features and requirements.

Sorry, but I cannot follow you. Is it about handling relations? From your
previous posts I understood that in your view "database operations" =
"operations on relations". If true => the question 2, if false => 1.

>:> I don't see why anyone using an Oracle DB would want to write
>:> stored procedures in Ada?
>: 
>: Fair enough. Compare: "I don't see why anybody using C would want to switch
>: to Ada". Indeed, they don't.
>  
> Some do switch from C to Ada, because Ada solves a problem.
> If the task at hand is to write a conditionally triggered
> procedure that processes a value before it is inserted into
> a table, and hides this fact away from a client, that's fairly
> easy in PL/SQL.

Writing triggered procedure is not an objective, it is a solution.

> It's just not there in Ada, AFAIKT.
>   What is your estimate of the effort it takes to merge this
> into Ada packages at a nice level of abstraction? For comparison,
> have a look at APQ, then at GNADE.

I do not see it as necessary for Ada.Databases. At some remote stage the
question: "how can I write and deploy a remote agent in Ada" may arise, but
in a more wide context of distributed systems support. From Ada.Databases
perspective, triggers, stored procedures etc are just gears to implement
abstract data base interface, whatever it will be. If your point is that
Ada's ADT is presently unsuitable for any good support for agents, then I
definitely agree. This is the main reason, why triggered procedures
*cannot* be exposed in the abstract interface.

> Have a look at Microsoft's WinFS plans. Consider how long it takes
> for the biggest and richest software company to come up with something
> working.

Huh, what about Windows (known to some as MS-DOS), it still does not work!
So the problem is elsewhere! (:-))

>: From my experience, there was no single case, when our customer didn't
>: ask for an extensible data model [and was told that he/she cannot afford
>: it]. Sooner or later they will break the wall.
> 
> Yes, sounds familiar, but first, hitting the wall is not equal to ruin
> as the technicians like to think ;-) and second, you'd have to demonstrate
> that an extended data model can be realized by just extending types.

Come on. When I keep on proposing for Ada a type model richer than just
extension, everybody tells that nobody would need that. Now you wish to
convince me that DB application area is wider than one of the most
universal programming language? (:-))

> It might be necessary to add or change change types and add or change
> relations between types etc.

Between objects, you mean? Because the only type relation the whole OO is
based on is just base<->derived. I do not believe, that DB would need
anything more advanced than that, really.

>:>: The same way we program concurrent distributed applications in Ada!
>:> 
>:> And you know what people say about task switching? Rendevous has
>:> its temporal aspects, how do you abstract them away?
>: 
>: I wouldn't. But it is perfectly possible. In C, which has no tasks, an
>: entry is replaced by a procedure with an additional parameter TimeOut.
> 
> So adding a TimeOut parameter is an abstraction of a task entry?

It is an abstraction of a timed entry call [we are talking about
interfaces.]

>: Basically I am unable to see any crucial difference between a data base
>: engine or embedded controller or JVM. Tell me
>: 
>: 1. Why Ada cannot be targeted there?
> 
> Who said so?
> 
>: 2. Why Ada will be less efficient than SQL?
> 
> Again, Ada /= SQL, see above. Efficiency here is not necessarily
> a matter of PLs, but of how an operation can be performed regardless
> of implementation language at either end of the communication.

Should it mean that the language is irrelevant here? What is the point
then?

> If the program is blocking resources due to generalized expectations
> about cursors in some nice DB abstraction there is an efficiency
> problem.

Again, the above is not about concrete languages Ada vs. SQL. It is rather
about if either Ada or SQL may define some "nice DB abstraction", which
won't cause efficiency problems. Surely any abstraction may cause them, yet
people are doomed to use them. After all SQL itself is also that sort of
abstraction.

> I was trying to explain that a program (being written in Ada or not)
> needs to be able to release database resources when proper working of
> the database software requires that this be done.

Fully agree.

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