Windows Ada database support.

Windows Ada database support.

[Mark Doherty]

I am developing a (GNAT 3.15p) ADA web (AWS) / Database (???)
application that will run on LINUX but developed on windows (xp).

What is the current best advice. GNADE / CLAW / GWINDOWS.Database
GNAVI, or something else?

Thanx Mark.

Re: Windows Ada database support.

[Marius Amado Alves]

Mark Doherty wrote:
> I am developing a (GNAT 3.15p) ADA web (AWS) / Database (???)
> application that will run on LINUX but developed on windows (xp).
> 
> What is the current best advice. GNADE / CLAW / GWINDOWS.Database
> GNAVI, or something else?

I don't think there can be a "best" advice. I would recommend my babies 
Mneson and Pgsql, in that order. Check AdaPower for more choices. The 
items you list above and Pgsql are all "bindings" to external systems. 
In AdaPower there are also "libraries" listed. With a library you can 
embbed the database with your application. Mneson is more developed than 
  the published version. Contact me if you're interested.

Re: Windows Ada database support.

[Pascal Obry]

mark_doherty@yahoo.co.uk (Mark Doherty) writes:

> What is the current best advice. GNADE / CLAW / GWINDOWS.Database
> GNAVI, or something else?

I would go for GNADE. AFAIK this is the only one (on the list above, not
counting "something else" of course :) to run on GNU/Linux and Windows. I have
lot of good experiences with GNADE (using ODBC) on both GNU/Linux and Windows.

Pascal.

-- 

--|------------------------------------------------------
--| Pascal Obry                           Team-Ada Member
--| 45, rue Gabriel Peri - 78114 Magny Les Hameaux FRANCE
--|------------------------------------------------------
--|              http://www.obry.org
--| "The best way to travel is by means of imagination"
--|
--| gpg --keyserver wwwkeys.pgp.net --recv-key C1082595

Re: Windows Ada database support.

[Alex R. Mosteo]

Pascal Obry wrote:
> mark_doherty@yahoo.co.uk (Mark Doherty) writes:
> 
> 
>>What is the current best advice. GNADE / CLAW / GWINDOWS.Database
>>GNAVI, or something else?
> 
> 
> I would go for GNADE. AFAIK this is the only one (on the list above, not
> counting "something else" of course :) to run on GNU/Linux and Windows. I have
> lot of good experiences with GNADE (using ODBC) on both GNU/Linux and Windows.

And I'm using the GNADE PSQL binding and it's really easy.

Re: Windows Ada database support.

[Dmitry A. Kazakov]

On Wed, 24 Nov 2004 20:17:58 +0100, Alex R. Mosteo wrote:

> Pascal Obry wrote:
>> mark_doherty@yahoo.co.uk (Mark Doherty) writes:
>> 
>>>What is the current best advice. GNADE / CLAW / GWINDOWS.Database
>>>GNAVI, or something else?
>> 
>> I would go for GNADE. AFAIK this is the only one (on the list above, not
>> counting "something else" of course :) to run on GNU/Linux and Windows. I have
>> lot of good experiences with GNADE (using ODBC) on both GNU/Linux and Windows.
> 
> And I'm using the GNADE PSQL binding and it's really easy.

GNADE ODBC bindings are easy. The problem is that ODBC itself ain't easy.
But if you want portability across different databases there is little
choice. The optimal choice could be GNADE ADBC, unfortunately, its
development was stopped.

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

Re: Windows Ada database support.

[Ching Bon Lam]

"Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> wrote in
news:1mmefmfb0ld12.1ahn4lp4c0nt1.dlg@40tude.net: 

> On Wed, 24 Nov 2004 20:17:58 +0100, Alex R. Mosteo wrote:
> 
>> Pascal Obry wrote:
>>> mark_doherty@yahoo.co.uk (Mark Doherty) writes:
>>> 
>>>>What is the current best advice. GNADE / CLAW / GWINDOWS.Database
>>>>GNAVI, or something else?
>>> 
>>> I would go for GNADE. AFAIK this is the only one (on the list above,
>>> not counting "something else" of course :) to run on GNU/Linux and
>>> Windows. I have lot of good experiences with GNADE (using ODBC) on
>>> both GNU/Linux and Windows. 
>> 
>> And I'm using the GNADE PSQL binding and it's really easy.
> 
> GNADE ODBC bindings are easy. The problem is that ODBC itself ain't
> easy. But if you want portability across different databases there is
> little choice. The optimal choice could be GNADE ADBC, unfortunately,
> its development was stopped.
> 

In GNADE CVS there is also Sqlite3 bindings which i wrote (dir dbi/sqlite). 
It supports quite most of the functions of sqlite3 except for user 
functions which you can call in SQL. It's still not much tested, but it's 
stable as far as i know.

www.sqlite.org
gnade.sf.net

C.B. Lam

Re: Windows Ada database support.

[David Botton]

On 2004-11-24 07:31:57 -0500, mark_doherty@yahoo.co.uk (Mark Doherty) said:
> 
> What is the current best advice. GNADE / CLAW / GWINDOWS.Database
> GNAVI, or something else?


They each serve different purpose. If your application is windows only 
(or doing GUI programming on windows using GNAVI), then using ADO via 
GWindows.Database or ADO bindings directly from GNATCOM are the likely 
winner.

Otherwise it is about your needs, I have an entire section on databases 
in AdaPower:

http://www.adapower.com/index.php?Command=Class&ClassID=Database

David Botton
http://www.adapower.com

Re: Windows Ada database support.

[bubble]

I have tryed GNade and GWindows.Database package before.
they are also easy to use.
I prefer GWindows.Database package because of  small and easy.

if you want running on Linux.
maybe you can try APQ. it seem very powerful.(I have no chance to try it.)
I not sure you can use gwindows.database package in linux environment.


GWindows sample code link:
http://en.wikibooks.org/wiki/Programming:Ada:Libraries:Database:GWindows

APQ link.
http://www.adapower.com/launch.php?URL=http%3A%2F%2Fgnade.sourceforge.net%2F



"Mark Doherty" <mark_doherty@yahoo.co.uk> ???
news:5e3e03a7.0411240431.7e037a4e@posting.google.com ???...
> I am developing a (GNAT 3.15p) ADA web (AWS) / Database (???)
> application that will run on LINUX but developed on windows (xp).
>
> What is the current best advice. GNADE / CLAW / GWINDOWS.Database
> GNAVI, or something else?
>
> Thanx Mark.

Re: Windows Ada database support.

[Warren W. Gay VE3WWG]

David Botton wrote:

> On 2004-11-24 07:31:57 -0500, mark_doherty@yahoo.co.uk (Mark Doherty) said:
> 
>> What is the current best advice. GNADE / CLAW / GWINDOWS.Database
>> GNAVI, or something else?
> 
> They each serve different purpose. If your application is windows only 
> (or doing GUI programming on windows using GNAVI), then using ADO via 
> GWindows.Database or ADO bindings directly from GNATCOM are the likely 
> winner.
> 
> Otherwise it is about your needs, I have an entire section on databases 
> in AdaPower:
> 
> http://www.adapower.com/index.php?Command=Class&ClassID=Database

APQ Plug:

The good news is that you do have "choice". I have been dragging my feet
in getting the latest version of APQ out, but the published version
supports PostgreSQL and MySQL in OO form. The version to be released
(pending install scripts), supports PostgreSQL, MySQL and SYBASE
(I have been distracted with another fun and absorbing project lately).

The OO level support is database neutral in most places, so that you
can write portable database code. Differences do exist however, but
this can be accomodated in the code if the programmer does a little
planning (avoid certain database features).

Good for Linux/Windows/*NIX, local or remote databases. The same
database code should compile to all platforms.

And... no *ODBC required. Totally native, no preprocessing of source
code. Also includes comprehensive manual with examples.

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

Re: Windows Ada database support.

[Dmitry A. Kazakov]

On Thu, 25 Nov 2004 12:50:07 -0500, Warren W. Gay VE3WWG wrote:

> David Botton wrote:
> 
>> On 2004-11-24 07:31:57 -0500, mark_doherty@yahoo.co.uk (Mark Doherty) said:
>> 
>>> What is the current best advice. GNADE / CLAW / GWINDOWS.Database
>>> GNAVI, or something else?
>> 
>> They each serve different purpose. If your application is windows only 
>> (or doing GUI programming on windows using GNAVI), then using ADO via 
>> GWindows.Database or ADO bindings directly from GNATCOM are the likely 
>> winner.
>> 
>> Otherwise it is about your needs, I have an entire section on databases 
>> in AdaPower:
>> 
>> http://www.adapower.com/index.php?Command=Class&ClassID=Database
> 
> APQ Plug:
> 
> The good news is that you do have "choice". I have been dragging my feet
> in getting the latest version of APQ out, but the published version
> supports PostgreSQL and MySQL in OO form. The version to be released
> (pending install scripts), supports PostgreSQL, MySQL and SYBASE
> (I have been distracted with another fun and absorbing project lately).
> 
> The OO level support is database neutral in most places, so that you
> can write portable database code. Differences do exist however, but
> this can be accomodated in the code if the programmer does a little
> planning (avoid certain database features).
> 
> Good for Linux/Windows/*NIX, local or remote databases. The same
> database code should compile to all platforms.
> 
> And... no *ODBC required. Totally native, no preprocessing of source
> code. Also includes comprehensive manual with examples.

What about support for MS-Access, MS-SQL server, Oracle?

And more importantly why that crappy SQL over and over again? I would like
to see a high level Ada.Database[.Relational?] package totally independent
on what happens beneath.

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

Re: Windows Ada database support.

[David Botton]

You have that on Win32 with GWindows.Databases it uses ADO which 
abstracts OLE-DB, ODBC, LDAP, and Mail, and much more.

David Botton

On 2004-11-26 04:15:06 -0500, "Dmitry A. Kazakov" 
<mailbox@dmitry-kazakov.de> said:
> What about support for MS-Access, MS-SQL server, Oracle?
> 
> And more importantly why that crappy SQL over and over again? I would like
> to see a high level Ada.Database[.Relational?] package totally independent
> on what happens beneath.

Re: Windows Ada database support.

[Dmitry A. Kazakov]

On Fri, 26 Nov 2004 13:36:42 -0500, David Botton wrote:

> You have that on Win32 with GWindows.Databases it uses ADO which 
> abstracts OLE-DB, ODBC, LDAP, and Mail, and much more.

But in some sense ADO is even worse than SomeDB-binding. At least databases
are more or less platform independent. In my view ADO is just as SQL, ODBC
and anything else. I would consider ADO as yet another database interface
to be abstracted away by our Ada(tm) way. So I am for Ada.Database in the
standard.

> On 2004-11-26 04:15:06 -0500, "Dmitry A. Kazakov" 
> <mailbox@dmitry-kazakov.de> said:
>> What about support for MS-Access, MS-SQL server, Oracle?
>> 
>> And more importantly why that crappy SQL over and over again? I would like
>> to see a high level Ada.Database[.Relational?] package totally independent
>> on what happens beneath.

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

Re: Windows Ada database support.

[David Botton]

I didn't pick up at the time you were talking about an Ada standard. 
ADO is just a way to offer an abstraction on Win32 (of course you get 
thick fairly easy to use Ada bindings to ADO via GNATCOM and even 
simpler via GWindows.Databases).

While I am not thrilled with the idea of create Ada standards for 
bindings to complex externals systems, a good look at the ADO way of 
doing things would certainly be a prerequisite to creating such a 
standard.

David Botton


On 2004-11-27 03:59:53 -0500, "Dmitry A. Kazakov" 
<mailbox@dmitry-kazakov.de> said:

> On Fri, 26 Nov 2004 13:36:42 -0500, David Botton wrote:
> 
>> You have that on Win32 with GWindows.Databases it uses ADO which 
>> abstracts OLE-DB, ODBC, LDAP, and Mail, and much more.
> 
> But in some sense ADO is even worse than SomeDB-binding. At least databases
> are more or less platform independent. In my view ADO is just as SQL, ODBC
> and anything else. I would consider ADO as yet another database interface
> to be abstracted away by our Ada(tm) way. So I am for Ada.Database in the
> standard.
> 
>> On 2004-11-26 04:15:06 -0500, "Dmitry A. Kazakov" 
>> <mailbox@dmitry-kazakov.de> said:
>>> What about support for MS-Access, MS-SQL server, Oracle?
>>> 
>>> And more importantly why that crappy SQL over and over again? I would like
>>> to see a high level Ada.Database[.Relational?] package totally independent
>>> on what happens beneath.

Re: Windows Ada database support.

[Dmitry A. Kazakov]

On Sat, 27 Nov 2004 19:46:58 -0500, David Botton wrote:

> While I am not thrilled with the idea of create Ada standards for 
> bindings to complex externals systems,

Yes, that would be too much to swallow. But I meant data bases, narrowly
understood. Also a data base is not necessarily an "external" system,
Berkeley DB for example. So it is not equivalent.

> a good look at the ADO way of 
> doing things would certainly be a prerequisite to creating such a 
> standard.

Undoubtedly. Though I am a bit sceptical about MS-ways. Just because they
changed their "standards" so often that it makes almost no sense to call
that standard. Maybe it is illogical, but to me the intention behind is as
important as the technical substance of a standard. Or better to say, that
substance can be better understood when the true intention is known...

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

Re: Windows Ada database support.

[Pascal Obry]

"Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> writes:

> On Sat, 27 Nov 2004 19:46:58 -0500, David Botton wrote:
> 
> > While I am not thrilled with the idea of create Ada standards for 
> > bindings to complex externals systems,
> 
> Yes, that would be too much to swallow. But I meant data bases, narrowly
> understood. Also a data base is not necessarily an "external" system,
> Berkeley DB for example. So it is not equivalent.

I think that if we want a database interface in the Ada standard it should be
based  on ODBC. ODBC is just that a cross-platform standard to access any
databases. Maybe it is not the best in term of performance but it is standard,
simple, comprehensive well known at this point... and it is always possible to
provide external high level libraries not in the standard.

Pascal.

-- 

--|------------------------------------------------------
--| Pascal Obry                           Team-Ada Member
--| 45, rue Gabriel Peri - 78114 Magny Les Hameaux FRANCE
--|------------------------------------------------------
--|              http://www.obry.org
--| "The best way to travel is by means of imagination"
--|
--| gpg --keyserver wwwkeys.pgp.net --recv-key C1082595

Re: Windows Ada database support.

[Dmitry A. Kazakov]

On 28 Nov 2004 11:23:31 +0100, Pascal Obry wrote:

> "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> writes:
> 
>> On Sat, 27 Nov 2004 19:46:58 -0500, David Botton wrote:
>> 
>>> While I am not thrilled with the idea of create Ada standards for 
>>> bindings to complex externals systems,
>> 
>> Yes, that would be too much to swallow. But I meant data bases, narrowly
>> understood. Also a data base is not necessarily an "external" system,
>> Berkeley DB for example. So it is not equivalent.
> 
> I think that if we want a database interface in the Ada standard it should be
> based  on ODBC. ODBC is just that a cross-platform standard to access any
> databases. Maybe it is not the best in term of performance but it is standard,
> simple, comprehensive well known at this point... and it is always possible to
> provide external high level libraries not in the standard.

I am not sure.

For one of my projects I even have implemented thick OO-ish bindings to
ODBC via GNADE, but I am not satisfied with ODBC. Not just because of
performance, which is awful. The very design of ODBC is something. It
abstracts SQL, but you still have to use SQL. So it takes the worst of two
worlds. Do you know, how to query via ODBC, if the data base supports
"PRIMARY KEY" in "CREATE TABLE"? The number of questions like that is
countless. The idea, ask how it spelt and tune the application in
accordance, is just idiotic. Ada's way(tm) is: I want "type X is range
1..100", go, do what should be done.

So in my view ODBC as an implementation (one of), yes of course, but as the
template for the standard, God save us!

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

Re: Windows Ada database support.

[Martin Dowie]

Dmitry A. Kazakov wrote:
> For one of my projects I even have implemented thick OO-ish bindings to
> ODBC via GNADE, but I am not satisfied with ODBC. Not just because of
> performance, which is awful. The very design of ODBC is something. It
> abstracts SQL, but you still have to use SQL. So it takes the worst of two
> worlds. Do you know, how to query via ODBC, if the data base supports
> "PRIMARY KEY" in "CREATE TABLE"? The number of questions like that is
> countless. The idea, ask how it spelt and tune the application in
> accordance, is just idiotic. Ada's way(tm) is: I want "type X is range
> 1..100", go, do what should be done.
> 
> So in my view ODBC as an implementation (one of), yes of course, but as the
> template for the standard, God save us!


For my degree I wrote a abstraction of a relational database in SML/NJ. 
It could be converted to Ada fairly simply - is that the sort of thing 
you mean? e.g.

package Relations is
    type Relation is private;
    ...
    procedure Union (X, Y : Relation; Result : out Relation);
    --  etc
end Relations;

Re: Windows Ada database support.

[Marius Amado Alves]

Martin Dowie wrote:
> For my degree I wrote a abstraction of a relational database in SML/NJ. 

This is interesting. What is SML/NJ and is your thesis accessible?

Re: Windows Ada database support.

[Dmitry A. Kazakov]

On Sun, 28 Nov 2004 14:38:49 +0000 (UTC), Martin Dowie wrote:

> Dmitry A. Kazakov wrote:
>> For one of my projects I even have implemented thick OO-ish bindings to
>> ODBC via GNADE, but I am not satisfied with ODBC. Not just because of
>> performance, which is awful. The very design of ODBC is something. It
>> abstracts SQL, but you still have to use SQL. So it takes the worst of two
>> worlds. Do you know, how to query via ODBC, if the data base supports
>> "PRIMARY KEY" in "CREATE TABLE"? The number of questions like that is
>> countless. The idea, ask how it spelt and tune the application in
>> accordance, is just idiotic. Ada's way(tm) is: I want "type X is range
>> 1..100", go, do what should be done.
>> 
>> So in my view ODBC as an implementation (one of), yes of course, but as the
>> template for the standard, God save us!
> 
> For my degree I wrote a abstraction of a relational database in SML/NJ. 
> It could be converted to Ada fairly simply - is that the sort of thing 
> you mean? e.g.
> 
> package Relations is
>     type Relation is private;
>     ...
>     procedure Union (X, Y : Relation; Result : out Relation);
>     --  etc
> end Relations;

Yes, though I am not sure whether a relational view is the best way of
abstraction. But an abstraction should be.

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

Re: Windows Ada database support.

[Marius Amado Alves]

Dmitry A. Kazakov wrote:
> Yes, though I am not sure whether a relational view is the best way of
> abstraction. But an abstraction should be.

For an alternative to the relational model see my Mneson system, based 
on a network model. The relational model is highly overrated. The most 
known network models e.g. CODASYL were not pure enough to constitute a 
true alternative, and now the world now only knows relational. Mneson is 
pure.

Re: Windows Ada database support.

[Pascal Obry]

"Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> writes:

> For one of my projects I even have implemented thick OO-ish bindings to
> ODBC via GNADE, but I am not satisfied with ODBC. Not just because of
> performance, which is awful. The very design of ODBC is something. It
> abstracts SQL, but you still have to use SQL. So it takes the worst of two

Well that the nice point. It gives you an interface to retrieve data from any
SQL statment. Are you really saying that you don't like SQL ? I'm not seeing
around another language is is capable of expressing very complexe requests
like SQL does.

Pascal.

-- 

--|------------------------------------------------------
--| Pascal Obry                           Team-Ada Member
--| 45, rue Gabriel Peri - 78114 Magny Les Hameaux FRANCE
--|------------------------------------------------------
--|              http://www.obry.org
--| "The best way to travel is by means of imagination"
--|
--| gpg --keyserver wwwkeys.pgp.net --recv-key C1082595

Re: Windows Ada database support.

[Dmitry A. Kazakov]

On Sun, 28 Nov 2004 17:47:34 +0000, Marius Amado Alves wrote:

> Dmitry A. Kazakov wrote:
>> Yes, though I am not sure whether a relational view is the best way of
>> abstraction. But an abstraction should be.
> 
> For an alternative to the relational model see my Mneson system, based 
> on a network model. The relational model is highly overrated. The most 
> known network models e.g. CODASYL were not pure enough to constitute a 
> true alternative, and now the world now only knows relational. Mneson is 
> pure.

Is anybody here to argue for an hierarchical model to complete the picture?
(:-))

Yes, in general I would agree with your assessment. 

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

Re: Windows Ada database support.

[Dmitry A. Kazakov]

On 28 Nov 2004 19:45:59 +0100, Pascal Obry wrote:

> "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> writes:
> 
>> For one of my projects I even have implemented thick OO-ish bindings to
>> ODBC via GNADE, but I am not satisfied with ODBC. Not just because of
>> performance, which is awful. The very design of ODBC is something. It
>> abstracts SQL, but you still have to use SQL. So it takes the worst of two
> 
> Well that the nice point. It gives you an interface to retrieve data from any
> SQL statment.

More to the point. It is XXI century. We are talking about *statements*, it
sounds like early 60s. Retrieving data, positioning cursors, stored
procedures. Is it about IBM 360 channel program? (:-))

> Are you really saying that you don't like SQL?

Yes, more than C++, even more than bash! (:-))

> I'm not seeing
> around another language is is capable of expressing very complexe requests
> like SQL does.

What about Ada! (no smiley now)

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

Re: Windows Ada database support.

[Martin Dowie]

Marius Amado Alves wrote:
> 
> Martin Dowie wrote:
> 
>> For my degree I wrote a abstraction of a relational database in SML/NJ. 
> 
> 
> This is interesting. What is SML/NJ and is your thesis accessible?

Thesis isn't available - that I know of!

SML/NJ - "Standard Meta-Language/New Jersey", http://www.smlnj.org/

I've loads of other stuff to do right now but I'll try a get a port 
together one day.

-- Martin

Re: Windows Ada database support.

[Pascal Obry]

"Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> writes:

> What about Ada! (no smiley now)

Well I love Ada as you probably know, but I do not see Ada as a good
replacement for SQL!

Pascal.

-- 

--|------------------------------------------------------
--| Pascal Obry                           Team-Ada Member
--| 45, rue Gabriel Peri - 78114 Magny Les Hameaux FRANCE
--|------------------------------------------------------
--|              http://www.obry.org
--| "The best way to travel is by means of imagination"
--|
--| gpg --keyserver wwwkeys.pgp.net --recv-key C1082595

Re: Windows Ada database support.

[Marius Amado Alves]

Pascal Obry wrote:
 > I'm not seeing
> around another language is is capable of expressing very complexe requests
> like SQL does.

XQuery, the Mneson Calculus and a host of other languages are no less 
expressive than SQL, and same much more elegant and sound.

Re: Windows Ada database support.

[Christopher Browne]

Marius Amado Alves <amado.alves@netcabo.pt> wrote:
> Martin Dowie wrote:
>> For my degree I wrote a abstraction of a relational database in
>> SML/NJ.
>
> This is interesting. What is SML/NJ and is your thesis accessible?

That's "Standard ML of New Jersey," a standards-compliant
implementation of ML.  <http://www.smlnj.org/>

Implementing a RDBMS in ML is an interesting idea...
-- 
select 'cbbrowne' || '@' || 'gmail.com';
http://www.ntlug.org/~cbbrowne/linuxdistributions.html
"Programming is an unnatural act." -- Alan Perlis

Re: Windows Ada database support.

[Georg Bauhaus]

Dmitry A. Kazakov <mailbox@dmitry-kazakov.de> wrote:
: And more importantly why that crappy SQL over and over again? I would like
: to see a high level Ada.Database[.Relational?] package totally independent
: on what happens beneath.

Because Ada is a high level systems programming language making
you expect to be in control of well defined details?

What about COMMIT? At what time should Oracle CURSORs be given
up? How much precision can you portably specify for floating point
values in your DB independent package?

-- Georg Bauhaus

Re: Windows Ada database support.

[Georg Bauhaus]

Marius Amado Alves <amado.alves@netcabo.pt> wrote:
: Pascal Obry wrote:
: > I'm not seeing
:> around another language is is capable of expressing very complexe requests
:> like SQL does.
: 
: XQuery, the Mneson Calculus and a host of other languages are no less 
: expressive than SQL, and same much more elegant and sound.

And read-only.

Re: Windows Ada database support.

[Dmitry A. Kazakov]

On Mon, 29 Nov 2004 01:28:03 +0000 (UTC), Georg Bauhaus wrote:

> Dmitry A. Kazakov <mailbox@dmitry-kazakov.de> wrote:
>: And more importantly why that crappy SQL over and over again? I would like
>: to see a high level Ada.Database[.Relational?] package totally independent
>: on what happens beneath.
> 
> Because Ada is a high level systems programming language making
> you expect to be in control of well defined details?

Yes.

> What about COMMIT?

That's easy. There should be a transaction object, kind of "external"
protected object.

BTW, there is an interesting Ada problem associated with it. When I wrote
ODBC bindings I faced this problem:

declare -- Transaction in manual-commit mode
   Mutex : Write_Mutex (Connection'Access);
begin
   ...  -- Do some DB stuff
   Commit (Mutex); -- Nasty, but necessary
end;

Upon exception Write_Mutex.Finalize does roll-back. This in turn requires
that nasty call to Commit at the end of the scope. Commit just sets a flag
in Write_Mutex for Finalize. Because in Finalize there is no way to
determine whether the scope was left due to a stack roll-back upon an
exception. Probably it is worth an AI for Ada 2010.

> At what time should Oracle CURSORs be given up?

What about n-th level of CPU cache? Do you really care when you write an
Ada application? It is all compiler vendor business. As an application
developer, I want to hear nothing about cursors.

> How much precision can you portably specify for floating point
> values in your DB independent package?

The required precision should specify the application. And BTW, for a great
majority of applications that should rather be fixed point. So you can't
have any default.

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

Re: Windows Ada database support.

[Dmitry A. Kazakov]

On 28 Nov 2004 21:04:57 +0100, Pascal Obry wrote:

> "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> writes:
> 
>> What about Ada! (no smiley now)
> 
> Well I love Ada as you probably know, but I do not see Ada as a good
> replacement for SQL!

I would not put it so wide. Let's narrow it: what is so special in data
bases, which makes impossible to use them with Ada? Maybe a flawed analogy,
but networking also started with some crippled "languages" like FTP and
Telnet.

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

Re: Windows Ada database support.

[Adrien Plisson]

Pascal Obry wrote:
> "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> writes:
>>What about Ada! (no smiley now)
> 
> Well I love Ada as you probably know, but I do not see Ada as a good
> replacement for SQL!

you two should try PL/SQL: it is SQL extended with an Ada syntax that 
allows you to write procedures...

if you love Ada, it will make you love SQL. if you love SQL, it will 
make you love Ada.

-- 
rien

Re: Windows Ada database support.

[Marius Amado Alves]

Georg Bauhaus wrote:
> Marius Amado Alves <amado.alves@netcabo.pt> wrote:
> : Pascal Obry wrote:
> : > I'm not seeing
> :> around another language is is capable of expressing very complexe requests
> :> like SQL does.
> : 
> : XQuery, the Mneson Calculus and a host of other languages are no less 
> : expressive than SQL, and same much more elegant and sound.
> 
> And read-only.

Sorry, I interpreted "request" as "query." Naturaly Mneson can update 
too. The two primitives are connect two vertices, disconnect two 
vertices. See also Mntext. (I'm working on Uniformal, the Mneson 
language that encompasses all these aspects. I can send drafts if wanted.)

XQuery cannot update, no. But I'm sure there is a subset of the myriad 
XLanguages that does. (Note I do not endorse the XML way. Mneson is 
partly a reaction to its *unnecessary* complexity.)

Re: Windows Ada database support.

[Alex R. Mosteo]

Adrien Plisson wrote:
> Pascal Obry wrote:
> 
>> "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> writes:
>>
>>> What about Ada! (no smiley now)
>>
>>
>> Well I love Ada as you probably know, but I do not see Ada as a good
>> replacement for SQL!
> 
> 
> you two should try PL/SQL: it is SQL extended with an Ada syntax that 
> allows you to write procedures...
> 
> if you love Ada, it will make you love SQL. if you love SQL, it will 
> make you love Ada.

Until you come to PL/SQL arrays ;) (or lack thereof).

But I love, for example, writing

for I in (select something from wherever) loop

Re: Windows Ada database support.

[Georg Bauhaus]

Dmitry A. Kazakov <mailbox@dmitry-kazakov.de> wrote:
: 
:  There should be a transaction object, kind of "external"
: protected object.

Interesting idea.

:> At what time should Oracle CURSORs be given up?
: 
: What about n-th level of CPU cache? Do you really care when you write an
: Ada application?

Is it unusual to think about hardware, timing, resources, ...
when you write an Ada application?
The moment my DB-software is to be portable, I might not want to have to think
about DB specific things. In the case of Oracle cursors it turns out that
you might have to manually free resources. Certainly this has effects
on the performance characteristics, design etc.
And my choice cannot be decided by the vendor.


: It is all compiler vendor business. As an application
: developer, I want to hear nothing about cursors.

Neither would I but I have to.

:> How much precision can you portably specify for floating point
:> values in your DB independent package?
: 
: The required precision should specify the application.

Yes but this also influences what will be in this version of that
DB.

Re: Windows Ada database support.

[Dmitry A. Kazakov]

On Mon, 29 Nov 2004 11:09:25 +0000 (UTC), Georg Bauhaus wrote:

> Dmitry A. Kazakov <mailbox@dmitry-kazakov.de> wrote:
>
>:> At what time should Oracle CURSORs be given up?
>: 
>: What about n-th level of CPU cache? Do you really care when you write an
>: Ada application?
> 
> Is it unusual to think about hardware, timing, resources, ...
> when you write an Ada application?

In terms of differences between P4 and AMD? One thinks about resources in
terms of the abstraction layer used in the application.

> The moment my DB-software is to be portable, I might not want to have to think
> about DB specific things. In the case of Oracle cursors it turns out that
> you might have to manually free resources. Certainly this has effects
> on the performance characteristics, design etc.
> And my choice cannot be decided by the vendor.

I meant the vendor of Ada.Database. It is up to the library implementation
to take care about all Oracle specific things directly or indirectly (over
ODBC, SQL or whatsoever layer). It is no different from, say, GTK, which
hides from you either Win32 or X11. You do not care about closing windows
handles when you are using GTK.

>: It is all compiler vendor business. As an application
>: developer, I want to hear nothing about cursors.
> 
> Neither would I but I have to.

Yes, because bindings are thin.

>:> How much precision can you portably specify for floating point
>:> values in your DB independent package?
>: 
>: The required precision should specify the application.
> 
> Yes but this also influences what will be in this version of that
> DB.

So what? As long as my application uses Ada.Database, I do not care.

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

Re: Windows Ada database support.

[Marius Amado Alves]

Dmitry A. Kazakov wrote:
> .. I would like
> to see a high level Ada.Database[.Relational?] package ...

There was a brief Ada Commentary on this early this year

    http://www.ada-auth.org/cgi-bin/cvsweb.cgi/AIs/AC-00097.TXT

which has overflowed to comp.lang.ada eventually as thread "Yet another 
XML and Ada issue"

Re: Windows Ada database support.

[Frank Piron]

Mon, 29 Nov 2004 12:00:17 +0100  Alex R. Mosteo <devnull@mailinator.com> 
wrote:

>> if you love Ada, it will make you love SQL. if you love SQL, it will 
>> make you love Ada.
>
> Until you come to PL/SQL arrays ;) (or lack thereof).

Yes. There are PL/SQL "Tables" (kind of sparse dynamic arrays).
But not handy for Ada people.

> But I love, for example, writing
>
> for I in (select something from wherever) loop

Implicit "cursor for loops" are beautiful until your app
run into the first "snapshot too old" error.

-- 
Frank Piron,
defrankatkonaddot
(leftrotate two)

Re: Windows Ada database support.

[Dmitry A. Kazakov]

On Mon, 29 Nov 2004 12:56:12 +0000, Marius Amado Alves wrote:

> Dmitry A. Kazakov wrote:
>> .. I would like
>> to see a high level Ada.Database[.Relational?] package ...
> 
> There was a brief Ada Commentary on this early this year
> 
>     http://www.ada-auth.org/cgi-bin/cvsweb.cgi/AIs/AC-00097.TXT
> 
> which has overflowed to comp.lang.ada eventually as thread "Yet another 
> XML and Ada issue"

Yes, and should be by "Annex E: Distributed Systems" instead...

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

Re: Windows Ada database support.

[Georg Bauhaus]

Dmitry A. Kazakov <mailbox@dmitry-kazakov.de> wrote:

:  It is no different from, say, GTK, which
: hides from you either Win32 or X11. You do not care about closing windows
: handles when you are using GTK.

Depending on how my application must use windows, I might have to think
about closing window handles.

:>: It is all compiler vendor business. As an application
:>: developer, I want to hear nothing about cursors.
:> 
:> Neither would I but I have to.
: 
: Yes, because bindings are thin.

No, I have to think about cursors because
- they have a life time,
- they are linked to a limited number of connections,
- they are a limited resource themselves,
- and they point to shared data, subject to updates.

This is interfacing to "world", not to some abstraction. The real
problems have got little to do with the thickness of bindings, I think.
In a multitasking, multiclient environment use of resources like cursors
pointing to shared structured data means a lot in terms of resources as
I'm sure you know. There is the additional burdon of managing a number
of transaction logs, which is costly, and might incur locking.
  See also Frank Piron's comment about implicit cursors in
PL/SQL.


:>:> How much precision can you portably specify for floating point
:>:> values in your DB independent package?
:>: 
:>: The required precision should specify the application.
:> 
:> Yes but this also influences what will be in this version of that
:> DB.
: 
: So what? As long as my application uses Ada.Database, I do not care.

You should care. For instance, you might have large amounts of numeric data
and your DB can store them as strings of decimal digits using thick
Ada.Database facilities, or else you have to manually tweak and force things
at low level and use tricks. Thick abstractions might take too much time.
Thick abstractions leave some choices behind. This isn't always helpful.

Re: Windows Ada database support.

[Frank Piron]

Fri, 26 Nov 2004 10:15:06 +0100 Dmitry A. Kazakov 
<mailbox@dmitry-kazakov.de> wrote:

> And more importantly why that crappy SQL over and over again? I would 
> like
> to see a high level Ada.Database[.Relational?] package totally 
> independent
> on what happens beneath.
>
But what language for querying and manipulating data would you
suggest?
IMO it should

- be declarative
- boolean closed
- allow restricted quantification

Some LQL (Logical query language based on Predicate Calculus)
would be nice.
Example: (Database for Genealogical data)

Base Predicates(Tables): Person(x,s), Parent(x,y)     |(s = sex)
Show all Fathers:

LQL:
Father(x):=E(y)[Person(x,s) and
                 s='MALE'    and
                 Parent(x,y)
                 ]

SQL:
select Person.x
      from Person, Parent
       where Person.s='MALE' and
             Person.x = Parent.x   (inner join for the E-Quantifier)

Similar to Prolog.

Other implementations would use only persistent types and their methods
in a distributed environment (like Cachￜ).

-- 
Frank Piron,
defrankatkonaddot
(leftrotate two)

Re: Windows Ada database support.

[Marius Amado Alves]

Frank Piron wrote:
> Base Predicates(Tables): Person(x,s), Parent(x,y)     |(s = sex)
> Show all Fathers:
> 
> LQL:
> Father(x):=E(y)[Person(x,s) and
>                 s='MALE'    and
>                 Parent(x,y)
>                 ]
> 
> SQL:
> select Person.x
>      from Person, Parent
>       where Person.s='MALE' and
>             Person.x = Parent.x   (inner join for the E-Quantifier)

In Mneson you would represent the parent, or child, relation simply as 
an attribute of a person, and then write something like

   targets (Person) ^ having (s, MALE) ^ having_any (child)

For robust validation of query languages I found two data sets:

- the ones included in XQuery published by w3c.org
- the benchmarks published by tpc.org

Maybe there are others; I'd like to know.

Re: Windows Ada database support.

[Dmitry A. Kazakov]

On Mon, 29 Nov 2004 14:07:45 +0000 (UTC), Georg Bauhaus wrote:

> Dmitry A. Kazakov <mailbox@dmitry-kazakov.de> wrote:
> 
>:  It is no different from, say, GTK, which
>: hides from you either Win32 or X11. You do not care about closing windows
>: handles when you are using GTK.
> 
> Depending on how my application must use windows, I might have to think
> about closing window handles.

... under X11.

>:>: It is all compiler vendor business. As an application
>:>: developer, I want to hear nothing about cursors.
>:> 
>:> Neither would I but I have to.
>: 
>: Yes, because bindings are thin.
> 
> No, I have to think about cursors because
> - they have a life time,
> - they are linked to a limited number of connections,
> - they are a limited resource themselves,
> - and they point to shared data, subject to updates.
> 
> This is interfacing to "world", not to some abstraction. The real
> problems have got little to do with the thickness of bindings, I think.
> In a multitasking, multiclient environment use of resources like cursors
> pointing to shared structured data means a lot in terms of resources as
> I'm sure you know. There is the additional burdon of managing a number
> of transaction logs, which is costly, and might incur locking.

Which only supports the point that cursor might be wrong abstraction.

>   See also Frank Piron's comment about implicit cursors in
> PL/SQL.
> 
>:>:> How much precision can you portably specify for floating point
>:>:> values in your DB independent package?
>:>: 
>:>: The required precision should specify the application.
>:> 
>:> Yes but this also influences what will be in this version of that
>:> DB.
>: 
>: So what? As long as my application uses Ada.Database, I do not care.
> 
> You should care. For instance, you might have large amounts of numeric data
> and your DB can store them as strings of decimal digits using thick
> Ada.Database facilities, or else you have to manually tweak and force things
> at low level and use tricks. Thick abstractions might take too much time.
> Thick abstractions leave some choices behind. This isn't always helpful.

Surely, but statistically irrelevant. Otherwise we would have no Ada and
still were programming in assembly. So there were no cursors, no data base
engines, no operating systems etc. Because one can always imagine a case,
where manual positioning of the hard drive heads could be essential for
performance.

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

Re: Windows Ada database support.

[Dmitry A. Kazakov]

On Mon, 29 Nov 2004 16:02:44 +0100, Frank Piron wrote:

> Fri, 26 Nov 2004 10:15:06 +0100 Dmitry A. Kazakov 
> <mailbox@dmitry-kazakov.de> wrote:
> 
>> And more importantly why that crappy SQL over and over again? I would 
>> like
>> to see a high level Ada.Database[.Relational?] package totally 
>> independent
>> on what happens beneath.
>>
> But what language for querying and manipulating data would you
> suggest?
> IMO it should
> 
> - be declarative
> - boolean closed
> - allow restricted quantification

Yes.

> Some LQL (Logical query language based on Predicate Calculus)
> would be nice.
> Example: (Database for Genealogical data)
> 
> Base Predicates(Tables): Person(x,s), Parent(x,y)     |(s = sex)
> Show all Fathers:
> 
> LQL:
> Father(x):=E(y)[Person(x,s) and
>                  s='MALE'    and
>                  Parent(x,y)
>                  ]
> 
> SQL:
> select Person.x
>       from Person, Parent
>        where Person.s='MALE' and
>              Person.x = Parent.x   (inner join for the E-Quantifier)
> 
> Similar to Prolog.
> 
> Other implementations would use only persistent types and their methods
> in a distributed environment (like Cach�).

Ideally it should be a direct use of Ada's ADT. It should be true ADT, not
just a data representation, also stored procedures (are they Turing
complete, BTW? (:-)) I don't know how realistic it will be in 2010, but
sooner or later a new generation of OO data bases will support ADT.

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

Re: Windows Ada database support.

[Georg Bauhaus]

Dmitry A. Kazakov <mailbox@dmitry-kazakov.de> wrote:
: On Mon, 29 Nov 2004 14:07:45 +0000 (UTC), Georg Bauhaus wrote:

:> This is interfacing to "world", not to some abstraction.
 
: Which only supports the point that cursor might be wrong abstraction.

Aha.

Cursors are not an abstraction from the point of view of an Ada
program.  SQL Cursors are a given part of the "world", in this case, the
data base system.  Go argue with Oracle Corp.


:>   See also Frank Piron's comment about implicit cursors in
:> PL/SQL.

Wrong abstractions in PL/SQL too?


:>: So what? As long as my application uses Ada.Database, I do not care.

Is this a motto?


:> Thick abstractions leave some choices behind. This isn't always helpful.
 
: Surely, but statistically irrelevant.

Aha. But allow me to say, as much as I'd wish to be able to use
a nice transparent, almost invisible interface to database system,
I see no base in reality for saying that abstraction thickness is
statistically irrelevant. For several reasons, and also because

- cursors do occur, no matter whether you express them behind Ada
  abstractions or not. Working with snapshots affects performance/
  shared resources to the point where you can no longer hide them relying
  on some AI system to free the resources automatically so the system
  keeps running.

  Working with RDBMSs means to have influence on another program's
  multiply shared data in soft real time! However, your program doesn't
  control that other program, your program must be well-behaved. Show me
  how to do this in some Ada.Databases.

- saying that performance/resources in database systems are statistically
  irrelevant makes me think that your perspective on DBs is different
  from mine, and probably not just mine ;-)

: Otherwise we would have no Ada and still were programming in assembly.

What has Ada versus Assembly got to do with resource consumption of
communicating programs (Ada program <-> database program?)
Other than trying a rhetorical trick to support a notion of statistical
irrelevance of SQL cursors in RDBMS? ;-)


-- Georg Bauhaus

Re: Windows Ada database support.

[Frank Piron]

Mon, 29 Nov 2004 19:16:18 +0100 Dmitry A. Kazakov 
<mailbox@dmitry-kazakov.de> wrote:

> Ideally it should be a direct use of Ada's ADT. It should be true ADT, 
> not
> just a data representation, also stored procedures (are they Turing
> complete, BTW? (:-))

In Oracle PL/SQL there are explicit restrictions on the size of
variables. But you may simulate a half-side Turing tape easily with
a suitable table (persistent or PL/SQL) and thus PL/SQL-Stored Procedures
are Turing complete with the usual assumption that tables are as large
as you want.

> I don't know how realistic it will be in 2010, but
> sooner or later a new generation of OO data bases will support ADT.
>

-- 
Frank Piron,
defrankatkonaddot
(leftrotate two)

Re: Windows Ada database support.

[Dmitry A. Kazakov]

On Mon, 29 Nov 2004 22:05:50 +0000 (UTC), Georg Bauhaus wrote:

> Dmitry A. Kazakov <mailbox@dmitry-kazakov.de> wrote:
>: On Mon, 29 Nov 2004 14:07:45 +0000 (UTC), Georg Bauhaus wrote:
> 
>:> This is interfacing to "world", not to some abstraction.
>  
>: Which only supports the point that cursor might be wrong abstraction.
> 
> Aha.
> 
> Cursors are not an abstraction from the point of view of an Ada
> program.  SQL Cursors are a given part of the "world", in this case, the
> data base system. Go argue with Oracle Corp.

You are mixing abstractions and things [of the "world"]. The goal of an
abstraction is to get rid of things [by replacing them by other, abstract,
things].

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

>:>: So what? As long as my application uses Ada.Database, I do not care.
> 
> Is this a motto?

As long as the goal is to have a generic data base interface.

>:> Thick abstractions leave some choices behind. This isn't always helpful.
>  
>: Surely, but statistically irrelevant.
> 
> Aha. But allow me to say, as much as I'd wish to be able to use
> a nice transparent, almost invisible interface to database system,
> I see no base in reality for saying that abstraction thickness is
> statistically irrelevant. For several reasons, and also because
> 
> - cursors do occur, no matter whether you express them behind Ada
>   abstractions or not. Working with snapshots affects performance/
>   shared resources to the point where you can no longer hide them relying
>   on some AI system to free the resources automatically so the system
>   keeps running.

This is a typical lack of abstraction. It is difficult to develop something
large, complex and concurrent using only arrays. As a matter of fact.

This is why thick bindings are so necessary. After all Ada's protected type
is just a thick binding to a chunk of raw memory. You may argue that
X'Address occur, would you?

>   Working with RDBMSs means to have influence on another program's
>   multiply shared data in soft real time! However, your program doesn't
>   control that other program, your program must be well-behaved. Show me
>   how to do this in some Ada.Databases.

The same way we program concurrent distributed applications in Ada! A
transaction is just an equivalent of protected procedure or rendezvous. For
more advanced technique you should have higher abstraction, you should go
ADT, OO, and so get rid of raw table views. Especially because there might
be data bases for which table views could be very inefficient.

> - saying that performance/resources in database systems are statistically
>   irrelevant makes me think that your perspective on DBs is different
>   from mine, and probably not just mine ;-)

Performance is relevant, but you cannot achieve it maintaining that low
level of abstraction. There is just a physical limit of application
complexity for each level. IMO, DB applications have outgrown tables and
cursors long time ago. Just look how many DB programmer positions are
offered. This is a significant indicator, that the technology is outdated.

>: Otherwise we would have no Ada and still were programming in assembly.
> 
> What has Ada versus Assembly got to do with resource consumption of
> communicating programs (Ada program <-> database program?)

It is because you present performance as an argument for using a low level
mechanism. It is a fundamentally flawed argument. The whole history of
computer development is against it.

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

Re: Windows Ada database support.

[Ole-Hjalmar Kristensen]

>>>>> "DAK" == Dmitry A Kazakov <mailbox@dmitry-kazakov.de> writes:
<snip>

    DAK> This is why thick bindings are so necessary. After all Ada's protected type
    DAK> is just a thick binding to a chunk of raw memory. You may argue that
    DAK> X'Address occur, would you?

    >> Working with RDBMSs means to have influence on another program's
    >> multiply shared data in soft real time! However, your program doesn't
    >> control that other program, your program must be well-behaved. Show me
    >> how to do this in some Ada.Databases.

    DAK> The same way we program concurrent distributed applications in Ada! A
    DAK> transaction is just an equivalent of protected procedure or rendezvous. For
    DAK> more advanced technique you should have higher abstraction, you should go
    DAK> ADT, OO, and so get rid of raw table views. Especially because there might
    DAK> be data bases for which table views could be very inefficient.

The transaction concept is significantly more powerful and complex
than protected procedures or rendezvous mechanisms in programming
languages. Unless your abstraction layer gives you full access to the
complete transaction apparatus in a DB-independent way, it simply
won't fly. You want to abstract away confusing details and differences
in implementation, not simplifying the underlying concept so much as
being unusable.

    >> - saying that performance/resources in database systems are statistically
    >> irrelevant makes me think that your perspective on DBs is different
    >> from mine, and probably not just mine ;-)

    DAK> Performance is relevant, but you cannot achieve it maintaining that low
    DAK> level of abstraction. There is just a physical limit of application
    DAK> complexity for each level. IMO, DB applications have outgrown tables and
    DAK> cursors long time ago. Just look how many DB programmer positions are
    DAK> offered. This is a significant indicator, that the technology is outdated.

Cursors are somewhat evil, and certainly over-used. Relational algebra
is not on a particularly low abstraction level, and certainly higher
than the typical procedural manipulations you do within a programming
language. It is certainly arguable whether there *are* better
abstractions than the (object) relational model at the moment.
Object-oriented databases certainly are not a better alternative for
most applications.

    >> : Otherwise we would have no Ada and still were programming in assembly.
    >> 
    >> What has Ada versus Assembly got to do with resource consumption of
    >> communicating programs (Ada program <-> database program?)

    DAK> It is because you present performance as an argument for using a low level
    DAK> mechanism. It is a fundamentally flawed argument. The whole history of
    DAK> computer development is against it.

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

-- 
   C++: The power, elegance and simplicity of a hand grenade.

Re: Windows Ada database support.

[Dmitry A. Kazakov]

On 30 Nov 2004 14:46:13 +0100, Ole-Hjalmar Kristensen wrote:

> The transaction concept is significantly more powerful and complex
> than protected procedures or rendezvous mechanisms in programming
> languages.

Transaction is an atomic change. It is definitely less powerful than
general notion of protected operation. Can you requeue a transaction? Can
you synchronize on a transaction?

> Cursors are somewhat evil, and certainly over-used. Relational algebra
> is not on a particularly low abstraction level, and certainly higher
> than the typical procedural manipulations you do within a programming
> language.

What makes you think so? If the above were true, then it would directly
imply Ada and other compilers should be written in SQL.

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

Re: Windows Ada database support.

[Georg Bauhaus]

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. I don't see why anyone using an Oracle DB would want to write
stored procedures in Ada?

 
:>:>: So what? As long as my application uses Ada.Database, I do not care.
:> 
:> Is this a motto?
: 
: As long as the goal is to have a generic data base interface.

Well, the prime goal for me has got to be an application that works
within the limits set by the RDBMS, in this case Oracle. If I have
to "descend" to sequential access or to random access via cursors,
so be it.

 
:  It is difficult to develop something
: large, complex and concurrent using only arrays. As a matter of fact.

Say that to someone you uses one of the array programming languages...

SQL is much more than just arrays. It also has sets and tables and
cursors.  Like Ada 2005.

Indeed RDBMSs have some low level features, but why not? There are
DBs based on different data structures, like extensible types.
Nice as they are, they do have real time limits, as a matter of fact.
And they do not always match the types of application data, which
can be of a rather fixed shape.
 
: 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? There are
others who want to use the database, too, so "could you please stop
shaking hands and give us some of the resources back if you don't
need them any longer!"


: ADT, OO, and so get rid of raw table views. Especially because there might
: be data bases for which table views could be very inefficient.

I'd leave RDBs only when table views are a burden, not because there
might be cases.

 
: IMO, DB applications have outgrown tables and
: cursors long time ago.

That may well depend on data. The "low level" Ada.Containers
might be used to implement something more abstract. Does every part of
a large Ada program outgrow Ada.Containers? How can I build a generic
abstraction on top of Ada.Containers that covers all aspects of
recourse consumption automagically?

BTW, thinking of accounting, the stock exchange,
time series, measurements, there are lots tabular data, and a sequence
of records is fine as a data structure. Something as useful as a list
together with predicates and recursion, depending on the application.
Or, in imperative terms, a vector together with predicates and
iteration?

However, if you look at SETL2 or Haskell (which does have type classes
which I'd guess you will like very much), there are cases where you
have to use dumb old ways of manipulating data in a "low level" way.
For example, you cannot just built a ton of sets and feed them to
existential quantifiers, because this will quickly consume all of
the available resources. Quicksort in SETL2 and Haskell is the
standard example.
This always happens the moment you have many data, or when you use high
level constructs in too generous combinations.

Can you present an efficient sort that is built around

 if # > 1 then
   sort {smaller} + arb + sort {larger}
 else
   arb
 end

and that is high level, ADT, OO, using available processors, etc.
and *still* uses a fairly small amount of memory in addition to
the memory consumed by data?


: Just look how many DB programmer positions are
: offered. This is a significant indicator, that the technology is outdated.

For me the number of database adminstrators/programmers has to do
with the number of significant installations and the number of
projects.
This number depends on the number of organisations, and on their
willingness/ability to invest. I don't think that the number of
wealthy organisations will change significantly because some
programming techniques evolve.

 
:> What has Ada versus Assembly got to do with resource consumption of
:> communicating programs (Ada program <-> database program?)
: 
: It is because you present performance as an argument for using a low level
: mechanism.

I present resource consumption as a real time constraint
on the structure of data and on techniques of data access.


: It is a fundamentally flawed argument. The whole history of
: computer development is against it.

The history of computer development has it, that there are commercially
viable successors to APL in use at companies using big data bases.
Incidentally, APL is a high level functional language built around
arrays...


-- Georg Bauhaus

Re: Windows Ada database support.

[Georg Bauhaus]

Ole-Hjalmar Kristensen <ole-hjalmar.kristensen@substitute_employer_here.com> wrote:

: You want to abstract away confusing details and differences
: in implementation, not simplifying the underlying concept so much as
: being unusable.

Thank you for saying this so clearly.


-- Georg Bauhaus

Re: Windows Ada database support.

[Dmitry A. Kazakov]

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?

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

>:>:>: So what? As long as my application uses Ada.Database, I do not care.
>:> 
>:> Is this a motto?
>: 
>: As long as the goal is to have a generic data base interface.
> 
> Well, the prime goal for me has got to be an application that works
> within the limits set by the RDBMS, in this case Oracle. If I have
> to "descend" to sequential access or to random access via cursors,
> so be it.

You could simply say: we need no generic data base interface.

>:  It is difficult to develop something
>: large, complex and concurrent using only arrays. As a matter of fact.
> 
> Say that to someone you uses one of the array programming languages...
> 
> SQL is much more than just arrays. It also has sets and tables and
> cursors.  Like Ada 2005.
> 
> Indeed RDBMSs have some low level features, but why not? There are
> DBs based on different data structures, like extensible types.
> Nice as they are, they do have real time limits, as a matter of fact.

So the point is: "real-time constraints cannot be met if data structures
are extensible"?

> And they do not always match the types of application data, which
> can be of a rather fixed shape.

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

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

> There are
> others who want to use the database, too, so "could you please stop
> shaking hands and give us some of the resources back if you don't
> need them any longer!"

I do not see why exposing, say, tasks should be less effective than hiding
them into connections, transactions whatsoever.

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?
2. Why Ada will be less efficient than SQL?

>: ADT, OO, and so get rid of raw table views. Especially because there might
>: be data bases for which table views could be very inefficient.
> 
> I'd leave RDBs only when table views are a burden, not because there
> might be cases.

OK, in data acquisition it is a heavy burden. Customers wish a table
(equidistant time, value1, value2 etc). But the system is event/data
driven. So the table basically contains useless garbage. Yet they still
want it, because tables are so cool.

>: Just look how many DB programmer positions are
>: offered. This is a significant indicator, that the technology is outdated.
> 
> For me the number of database adminstrators/programmers has to do
> with the number of significant installations and the number of
> projects.
> This number depends on the number of organisations, and on their
> willingness/ability to invest. I don't think that the number of
> wealthy organisations will change significantly because some
> programming techniques evolve.

They will invest in other things. Nowadays, nobody invests in chopping
firewood...

>:> What has Ada versus Assembly got to do with resource consumption of
>:> communicating programs (Ada program <-> database program?)
>: 
>: It is because you present performance as an argument for using a low level
>: mechanism.
> 
> I present resource consumption as a real time constraint
> on the structure of data and on techniques of data access.

But you do not explain why SELECT * is less resource consuming than
anything else.

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

Re: Windows Ada database support.

[Georg Bauhaus]

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.



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

 
: You could simply say: we need no generic data base interface.
 
In fact we have convenience objects, but still it is necessary that we
can get through to the database.

 
: So the point is: "real-time constraints cannot be met if data structures
: are extensible"?

If real-time constraints cannot be met using a DB system storing
more fancy data structures, I have to look for an alternative
solution. The opposite direction away from RDBs seems to be a big problem;
as has been mentioned, we have some object-relational DBs, 
some more advance O-O DBs, and some DBs that can store XML-like
documents.

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. Substract compatibility issues and the profit made by selling
interim improvements. Is it easy to build something that covers
more than RDBMSs do?


:> And they do not always match the types of application data, which
:> can be of a rather fixed shape.
 
: Why?

There are things whose property set doesn't change frequently ;-)

: 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.
It might be necessary to add or change change types and add or change
relations between types etc.


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

 
: 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. If
the program is blocking resources due to generalized expectations
about cursors in some nice DB abstraction there is an efficiency
problem.

 
: They will invest in other things. Nowadays, nobody invests in chopping
: firewood...

Well, some do. (I've had to find firewood and briquettes for some 10 years,
so I know. And those who have nice firesides in their homes need it, too.)

 
:>:> What has Ada versus Assembly got to do with resource consumption of
:>:> communicating programs (Ada program <-> database program?)
:>: 
:>: It is because you present performance as an argument for using a low level
:>: mechanism.
:> 
:> I present resource consumption as a real time constraint
:> on the structure of data and on techniques of data access.
: 
: But you do not explain why SELECT * is less resource consuming than
: anything else.

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. If an abstraction
doesn't offer this possibility, then I cannot use the abstraction.

Since I am in no position to discuss the difficult task of designing
a modern database system, I'll leave this to others now. :-)


-- Georg

Re: Windows Ada database support.

[Dmitry A. Kazakov]

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

Re: Windows Ada database support.

[Pascal Obry]

Adrien Plisson <aplisson-news@stochastique.net> writes:

> Pascal Obry wrote:
> > "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> writes:
> >>What about Ada! (no smiley now)
> > Well I love Ada as you probably know, but I do not see Ada as a good
> > replacement for SQL!

I know PL/SQL and I like it indeed !

Pascal.

-- 

--|------------------------------------------------------
--| Pascal Obry                           Team-Ada Member
--| 45, rue Gabriel Peri - 78114 Magny Les Hameaux FRANCE
--|------------------------------------------------------
--|              http://www.obry.org
--| "The best way to travel is by means of imagination"
--|
--| gpg --keyserver wwwkeys.pgp.net --recv-key C1082595

Re: Windows Ada database support.

[Marius Amado Alves]

"I know PL/SQL and I like it indeed !" (Pascal.)

And the fact that it looks a lot like Ada has nothing to do with it :-)

Re: Windows Ada database support.

[Frank Piron]

Am Thu, 02 Dec 2004 10:37:22 +0000 schrieb Marius Amado Alves 
<amado.alves@netcabo.pt>:

> "I know PL/SQL and I like it indeed !" (Pascal.)
>
> And the fact that it looks a lot like Ada has nothing to do with it :-)
>
I was pointed to Ada via PL/SQL, because i read somewhere in the
Oracle Doc that PL/SQL was initially derived from Ada83.
-- 
Frank Piron,
defrankatkonaddot
(leftrotate two)

Re: Windows Ada database support.

[John B. Matthews]

In article 
<mailman.166.1101983875.10401.comp.lang.ada@ada-france.org>,
 Marius Amado Alves <amado.alves@netcabo.pt> wrote:

> "I know PL/SQL and I like it indeed !" (Pascal.)
> 
> And the fact that it looks a lot like Ada has nothing to do with it :-)

Server-side procedures with Ada syntax! What's not to like? :-)

To understand PL/SQL, it's helpful to recall that SQL is a 
declarative language: the desired result is specified; the details 
of getting that result are not. PL/SQL is a procedural "wrapper" 
that permits embedded SQL statements to be executed and the results 
examined.

PL/SQL's use of Ada syntax lends a pleasant clarity to database 
programming. In particular, the Ada package concept allows related 
database objects to be grouped together in a familiar ADT style.

Veterans of Ada may be disappointed by the relative lack of support 
for type extension and concurrency. In its defense, PL/SQL fully 
supports a rich set of database types, and concurrency is handled by 
the database engine itself.

You can learn more about PL/SQL from the corresponding Oracle 
manual. It's available on TechNet, registration required:

<http://download-west.oracle.com/docs/cd/B14117_01/appdev.101/b10807/
toc.htm>

-- 
John
jmatthews at wright dot edu
www dot wright dot edu/~john.matthews/

Re: Windows Ada database support.

[Warren W. Gay VE3WWG]

Dmitry A. Kazakov wrote:
> On Thu, 25 Nov 2004 12:50:07 -0500, Warren W. Gay VE3WWG wrote:
...
>>APQ Plug:
>>
>>The good news is that you do have "choice". I have been dragging my feet
>>in getting the latest version of APQ out, but the published version
>>supports PostgreSQL and MySQL in OO form. The version to be released
>>(pending install scripts), supports PostgreSQL, MySQL and SYBASE
>>(I have been distracted with another fun and absorbing project lately).
>>
>>The OO level support is database neutral in most places, so that you
>>can write portable database code. Differences do exist however, but
>>this can be accomodated in the code if the programmer does a little
>>planning (avoid certain database features).
>>
>>Good for Linux/Windows/*NIX, local or remote databases. The same
>>database code should compile to all platforms.
>>
>>And... no *ODBC required. Totally native, no preprocessing of source
>>code. Also includes comprehensive manual with examples.
> 
> What about support for MS-Access, MS-SQL server, Oracle?

When I get the time to put APQ up on Source Forge, then these
shouldn't be hard to add to APQ, but volunteers.

> And more importantly why that crappy SQL over and over again? I would like
> to see a high level Ada.Database[.Relational?] package totally independent
> on what happens beneath.

On the relational side, it is currently near impossible to be
"totally independent on what happens beneath". However, I believe
APQ comes close (this was one of its design goals).

I don't really understand your criticism "why that crappy SQL over
and over again?". I do recognize that SQL as implemented by the
various vendors could use more uniformity, and even then is less
than perfect. However, most people find that the current crop
of relational databases are far superior to the old days of
updating files without atomic transactions and referencial
integrity. So I would tend to agree with the general feeling
that the SQL products today, are "good enough".

Keep in mind that you cannot use a relational database without
using SQL (at least no examples come to my mind). So if you
don't like SQL, then you have to either forget relational,
or build a higher level "protocol" that compiles/translates
to SQL underneath.

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

Re: Windows Ada database support.

[Warren W. Gay VE3WWG]

Dmitry A. Kazakov wrote:

> On Sun, 28 Nov 2004 17:47:34 +0000, Marius Amado Alves wrote:
>>Dmitry A. Kazakov wrote:
>>
>>>Yes, though I am not sure whether a relational view is the best way of
>>>abstraction. But an abstraction should be.
>>
>>For an alternative to the relational model see my Mneson system, based 
>>on a network model. The relational model is highly overrated. The most 
>>known network models e.g. CODASYL were not pure enough to constitute a 
>>true alternative, and now the world now only knows relational. Mneson is 
>>pure.
> 
> Is anybody here to argue for an hierarchical model to complete the picture?
> (:-))
> 
> Yes, in general I would agree with your assessment. 

Theory is fine and dandy, and I support the concept of research. In fact
it would be better if there was more of that going on.

But whether research is happening in earnest or not, doesn't much matter
to folks that must write applications today. They need to work with
existing products. SQL relational databases, still represents the most
practical choice for many applications. And the reason of course that
databases are discussed here, is people want to use them effectively
from Ada.

For hierarchical databases, you have some choices (Windows Registry is
one kind of "hierarchical database", though I have issues with its
design and use ;-)

Because the Reiser file system makes efficient use of disk space, a
subdirectory structure can be used nicely as a hierarchical database.
This can be neatly wrapped up in a nice Ada API (something on my
TODO list).

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

Re: Windows Ada database support.

[Dmitry A. Kazakov]

On Mon, 06 Dec 2004 09:48:09 -0500, Warren W. Gay VE3WWG wrote:

> Dmitry A. Kazakov wrote:
>> On Thu, 25 Nov 2004 12:50:07 -0500, Warren W. Gay VE3WWG wrote:
> ...
>>>APQ Plug:
>>>
>>>The good news is that you do have "choice". I have been dragging my feet
>>>in getting the latest version of APQ out, but the published version
>>>supports PostgreSQL and MySQL in OO form. The version to be released
>>>(pending install scripts), supports PostgreSQL, MySQL and SYBASE
>>>(I have been distracted with another fun and absorbing project lately).
>>>
>>>The OO level support is database neutral in most places, so that you
>>>can write portable database code. Differences do exist however, but
>>>this can be accomodated in the code if the programmer does a little
>>>planning (avoid certain database features).
>>>
>>>Good for Linux/Windows/*NIX, local or remote databases. The same
>>>database code should compile to all platforms.
>>>
>>>And... no *ODBC required. Totally native, no preprocessing of source
>>>code. Also includes comprehensive manual with examples.
>> 
>> What about support for MS-Access, MS-SQL server, Oracle?
> 
> When I get the time to put APQ up on Source Forge, then these
> shouldn't be hard to add to APQ, but volunteers.
> 
>> And more importantly why that crappy SQL over and over again? I would like
>> to see a high level Ada.Database[.Relational?] package totally independent
>> on what happens beneath.
> 
> On the relational side, it is currently near impossible to be
> "totally independent on what happens beneath". However, I believe
> APQ comes close (this was one of its design goals).
> 
> I don't really understand your criticism "why that crappy SQL over
> and over again?". I do recognize that SQL as implemented by the
> various vendors could use more uniformity, and even then is less
> than perfect. However, most people find that the current crop
> of relational databases are far superior to the old days of
> updating files without atomic transactions and referencial
> integrity. So I would tend to agree with the general feeling
> that the SQL products today, are "good enough".
> 
> Keep in mind that you cannot use a relational database without
> using SQL (at least no examples come to my mind). So if you
> don't like SQL, then you have to either forget relational,
> or build a higher level "protocol" that compiles/translates
> to SQL underneath.

Yes, this is exactly what I meant. In short, Ada bindings should have
Create_Table (...) instead of Execute ("CREATE TABLE ..."). Let SQL be
perfect, firmly standardized, validated etc. Even so to have a language
within another language is a bad idea.

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

Re: Windows Ada database support.

[Warren W. Gay VE3WWG]

Dmitry A. Kazakov wrote:
> On Mon, 06 Dec 2004 09:48:09 -0500, Warren W. Gay VE3WWG wrote:
...
>>Keep in mind that you cannot use a relational database without
>>using SQL (at least no examples come to my mind). So if you
>>don't like SQL, then you have to either forget relational,
>>or build a higher level "protocol" that compiles/translates
>>to SQL underneath.
> 
> Yes, this is exactly what I meant. In short, Ada bindings should have
> Create_Table (...) instead of Execute ("CREATE TABLE ..."). Let SQL be
> perfect, firmly standardized, validated etc. Even so to have a language
> within another language is a bad idea.

This problem is virtually unsolvable with the existing products
that people out there use. Some database products (PostgreSQL
for example) promote the use of Object IDs (basically Row IDs).
Still others don't support the concept at all (MySQL). A grey
area exists in a 3rd area (like Informix), which allows you to
use them at your own peril (Row IDs are unique, if you keep
within certain database design restrictions).

Related to this same issue is how to identify rows that lack
a natural primary key. Some databases support an identity
type for the purpose (Sybase), while others use sequences.
Still others like MySQL use some weird idea of an auto
increment integer field (I am too lazy to look up the
specifics for this, but this is documented in the APQ
manual).

Here's another good one: Some databases allow you to declare
a VARCHAR(256). Others are restricted to VARCHAR(255), and you
must switch to a different type (TEXT I think), if you need
longer fields.

Some support boolean types, and others do not. Some support
arrays, others do not. If they both support arrays, they
are guaranteed to work with different rules and syntax.

There seems to be virtually no agreement on how blobs are
handled and managed, between the different products.

The list of incompatibilities and differences are many
more. For example, there are differences in the way the
client libraries work (ability to fetch one row at a time,
randomly or not (PostgreSQL), must fetch them all into
client memory for random access, or use one-at-a-time
sequential access (MySQL), etc.)

The challenges for a "unified Ada access" layer are so
numerous, that I consider it unachievable. I took a stab
at providing a "portable" binding in APQ, but had to
make various compromises along the way (these are documented
in the manual).

I support the concept, but unless dramatic changes in
product lines emerge, you cannot arrive at the "I
don't want to know what is beneath" solution.  APQ
takes a stab at this problem, and does reduce or
eliminate many of the differences. Truly portable
code will still need to test which database product
is being used, and adjust the SQL to suit in some
cases. There is just no way to avoid it.

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

Re: Windows Ada database support.

[Georg Bauhaus]

Warren W. Gay VE3WWG <ve3wwg@nospam.cogeco.ca> wrote:
: Still others like MySQL use some weird idea of an auto
: increment integer field (I am too lazy to look up the
: specifics for this, but this is documented in the APQ
: manual).

In fact the MySQL auto increment ids are no more than a
convenience, you can actually overwrite the keys at will,
with interesting side effects. (A customer has asked us to
change internal auto inc keys, because they had told another
company the internal ids and had assumed auto inc ids would be
the same on different computers running different DB instances
at differnt times... At another installation site, the DB is
Oracle.  They have been warned...)


: Here's another good one: Some databases allow you to declare
: a VARCHAR(256). Others are restricted to VARCHAR(255), and you
: must switch to a different type (TEXT I think), if you need
: longer fields.

In addition, depending on database version and driver,
Oracle might give you quite a variety of types for each of
text fields, floats, and others.

 
-- Georg

Re: Windows Ada database support.

[Dmitry A. Kazakov]

On Mon, 06 Dec 2004 12:52:40 -0500, Warren W. Gay VE3WWG wrote:

> Dmitry A. Kazakov wrote:
>> On Mon, 06 Dec 2004 09:48:09 -0500, Warren W. Gay VE3WWG wrote:
> ...
>>>Keep in mind that you cannot use a relational database without
>>>using SQL (at least no examples come to my mind). So if you
>>>don't like SQL, then you have to either forget relational,
>>>or build a higher level "protocol" that compiles/translates
>>>to SQL underneath.
>> 
>> Yes, this is exactly what I meant. In short, Ada bindings should have
>> Create_Table (...) instead of Execute ("CREATE TABLE ..."). Let SQL be
>> perfect, firmly standardized, validated etc. Even so to have a language
>> within another language is a bad idea.
> 
> This problem is virtually unsolvable with the existing products

(SQL products)

> that people out there use. Some database products (PostgreSQL
> for example) promote the use of Object IDs (basically Row IDs).
> Still others don't support the concept at all (MySQL). A grey
> area exists in a 3rd area (like Informix), which allows you to
> use them at your own peril (Row IDs are unique, if you keep
> within certain database design restrictions).

I think that this is a shortcoming of the very concept of a relational
view. Relation is not an array. Period. So IF it should be
Ada.Database.Relational, then there will be no such think as row ID. [ But
it is a good sign. Database vendors start to conceive shortcomings of the
existing models. This will erode SQL dominance. ]

Also we should distinguish two cases:

A. Some Ada application stores its data in a database. The way the data are
organized there is free.

B. Accessing existing (but unknown at design time) data base. The data
structure is fixed and the application must adapt to it.

A is much easier than B. Not everybody needs B. Further B is often bound to
some concrete data base, in which case data base specific bindings make
much sense. So we could ignore B for a while. At least until it will be
clear how to provide at least A.

> Related to this same issue is how to identify rows that lack
> a natural primary key. Some databases support an identity
> type for the purpose (Sybase), while others use sequences.
> Still others like MySQL use some weird idea of an auto
> increment integer field (I am too lazy to look up the
> specifics for this, but this is documented in the APQ
> manual).
> 
> Here's another good one: Some databases allow you to declare
> a VARCHAR(256). Others are restricted to VARCHAR(255), and you
> must switch to a different type (TEXT I think), if you need
> longer fields.
> 
> Some support boolean types, and others do not. Some support
> arrays, others do not. If they both support arrays, they
> are guaranteed to work with different rules and syntax.
> 
> There seems to be virtually no agreement on how blobs are
> handled and managed, between the different products.

This is the case B. I think that it could still be possible to solve it in
an OO way. All database types should be derived from one base. Factory can
be used to create values "like in the column". Differences between VARCHAR,
TEXT, LONGCHAR etc are uninteresting for the application. It should have
some string type derived from the base. That may have constrained subtypes
or derived types according to the database constraints.

In general I do not think that primitive data types are the greatest
problem. The problem is that the semantics of "what and how" slips away. It
is too low level.

> The list of incompatibilities and differences are many
> more. For example, there are differences in the way the
> client libraries work (ability to fetch one row at a time,
> randomly or not (PostgreSQL), must fetch them all into
> client memory for random access, or use one-at-a-time
> sequential access (MySQL), etc.)
> 
> The challenges for a "unified Ada access" layer are so
> numerous, that I consider it unachievable. I took a stab
> at providing a "portable" binding in APQ, but had to
> make various compromises along the way (these are documented
> in the manual).

I think that APQ could become an alternative to ODBC. ODBC tries to swallow
documents and spreadsheets (like Excel), things that are too far from a
"normal" data base.

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

Re: Windows Ada database support.

[Warren W. Gay VE3WWG]

Dmitry A. Kazakov wrote:
> On Mon, 06 Dec 2004 12:52:40 -0500, Warren W. Gay VE3WWG wrote:
>>that people out there use. Some database products (PostgreSQL
>>for example) promote the use of Object IDs (basically Row IDs).
>>Still others don't support the concept at all (MySQL). A grey
>>area exists in a 3rd area (like Informix), which allows you to
>>use them at your own peril (Row IDs are unique, if you keep
>>within certain database design restrictions).
> 
> I think that this is a shortcoming of the very concept of a relational
> view. Relation is not an array. Period. So IF it should be
> Ada.Database.Relational, then there will be no such think as row ID. [ But
> it is a good sign. Database vendors start to conceive shortcomings of the
> existing models. This will erode SQL dominance. ]

Well, database theory experts rage wars over issues like this
in other newsgroups. All I would personally like to see on a
practical level (theory aside) is AGREEMENT and CONSISTENCY.
I could live with or without row IDs, as long as all vendors
did so uniformly. As soon as one supports the idea, then any
Ada package that binds to it must provide access to it (existing
database schemas are not going to change to suit the Ada
package writer).

OTOH, I have no problem WITH row ids, as long as they are unique.
The whole row ID problem AFAIK, only really started to be a
problem when vendors started permitting other disk configurations
that caused the row ids to be "parallel" in some way, and thus
non-unique.

> Also we should distinguish two cases:
> 
> A. Some Ada application stores its data in a database. The way the data are
> organized there is free.

Its not clear to me what you mean by "free" here.

> B. Accessing existing (but unknown at design time) data base. The data
> structure is fixed and the application must adapt to it.

I think I know the two points you are raising, but it isn't
clear which is A or B.

> A is much easier than B. Not everybody needs B. Further B is often bound to
> some concrete data base, in which case data base specific bindings make
> much sense. So we could ignore B for a while. At least until it will be
> clear how to provide at least A.

If in one case you mean a package capable of being used in a GUI
tool, where it can connect to the database and discover tables,
keys, indexes, views, triggers and the like, and allow dynamic
operations without any foreknowledge, then agreed, this is much
more difficult. This is even more of a nightmare approach wise,
because the standard(s) never addressed this need - hence every
vendor implements this functionality they way they see fit.

While the above is import (for tools), application needs are usually
much simpler. Written to do fixed operations, on a fixed set of
tables, views and stored procedures. But as I've pointed out,
even this simpler case is complex in a multi-vendor world.

>>Related to this same issue is how to identify rows that lack
>>a natural primary key. Some databases support an identity
>>type for the purpose (Sybase), while others use sequences.
>>Still others like MySQL use some weird idea of an auto
>>increment integer field (I am too lazy to look up the
>>specifics for this, but this is documented in the APQ
>>manual).
>>
>>Here's another good one: Some databases allow you to declare
>>a VARCHAR(256). Others are restricted to VARCHAR(255), and you
>>must switch to a different type (TEXT I think), if you need
>>longer fields.
>>
>>Some support boolean types, and others do not. Some support
>>arrays, others do not. If they both support arrays, they
>>are guaranteed to work with different rules and syntax.
>>
>>There seems to be virtually no agreement on how blobs are
>>handled and managed, between the different products.
> 
> This is the case B. 

Blobs?

>I think that it could still be possible to solve it in
> an OO way. 

I beg to differ on this one, though I've not tried very
hard on this one ;-)  Consider some of the challenges:

1) PostgreSQL uses an API that opens/creates etc. and returns
    an OID.
2) PostgreSQL blobs are referenced by saving a OID in a column
    of a row.
3) ALL PostgreSQL blob operations must occur within the confines
    of a transaction (otherwise the operation fails!)
4) MySQL (IIRC), wants you to put the entire blob into a
    row.
5) MySQL, IIRC, wants you to perform the blob I/O in one
    operation and IIRC, doesn't care about transactions (optional).
6) PostgreSQL blobs can be operated on like files, with seeks,
    partial writes, reads etc.

I seem to recall there were more problems, but when I started
with this list, I decided to leave it for a rainy day!!! ;-)

> All database types should be derived from one base. Factory can
> be used to create values "like in the column". Differences between VARCHAR,
> TEXT, LONGCHAR etc are uninteresting for the application. 

You might expect so, but the Boolean case and Dates have created
a lot of problem. Since you have to work with SQL, how do you
satisfy databases that want 0 and 1 for Booleans (or bit?),
and the more nomal ones that that True and False?

I sheltered the application to some degree from this in APQ,
but allowing the fields to be encoded for you (APQ knows
in the MySQL case it wants 0 and 1 - I think it was MySQL).
But this problem still pokes out in places like hardcoded WHERE
clauses :

...
WHERE MARRIED = False and ...

or

WHERE MARRIED = 0 and ...

So if MARRIED is BOOLEAN, I think you have to test if you
are using MySQL (I think it was them), and then use the 0
and 1 instead (or use APQ to encode a hardcoded False!)

Dates, Timestamps and timezones get even more interesting.
Versions of databases add to the problems! MySQL in one
version formats the dates differently than later versions
-- ugh!

> In general I do not think that primitive data types are the greatest
> problem. The problem is that the semantics of "what and how" slips away. It
> is too low level.

I think you would be surprised! Just sticking to "normal"
primitive data types in APQ, has had me see enough horrors ;-)

>>The list of incompatibilities and differences are many
>>more. For example, there are differences in the way the
>>client libraries work (ability to fetch one row at a time,
>>randomly or not (PostgreSQL), must fetch them all into
>>client memory for random access, or use one-at-a-time
>>sequential access (MySQL), etc.)
>>
>>The challenges for a "unified Ada access" layer are so
>>numerous, that I consider it unachievable. I took a stab
>>at providing a "portable" binding in APQ, but had to
>>make various compromises along the way (these are documented
>>in the manual).
> 
> I think that APQ could become an alternative to ODBC. ODBC tries to swallow
> documents and spreadsheets (like Excel), things that are too far from a
> "normal" data base.

Well, in fairness to ODBC, some sort of generalized interface
was called for, and it was "a solution" of sorts. But I never
felt it was meant to be used by application programmers. IMHO,
any API that has application programmers coding a whole whack
of complex API calls to just do a select and return a row (for
example), is not "the solution". Application programmers want
to focus on the application problem - not API details (most
mediochre programmers can't get it right anyway). Once coded,
it becomes so complex, that no one wants to make major changes
to it. Then comes the patchwork!

Many people feel that code generators are the answer. I disagree
there also. That is a one-time fix. Eventually, someone has to
go back and change it. At this point it is unreadable and near
unmaintainable.

APQ tries to make it simple for the application programmer. I
would much rather be thinking in SQL and Ada terms, than trying
trying to remember API calls. APQ's API tries to be self
intuitive, and time will tell if it is or not.

This has been an interesting diversion ;-)
-- 
Warren W. Gay VE3WWG
http://home.cogeco.ca/~ve3wwg

Re: Windows Ada database support.

[Dmitry A. Kazakov]

On Tue, 07 Dec 2004 00:16:21 -0500, Warren W. Gay VE3WWG wrote:

> Dmitry A. Kazakov wrote:
>> On Mon, 06 Dec 2004 12:52:40 -0500, Warren W. Gay VE3WWG wrote:

>> Also we should distinguish two cases:
>> 
>> A. Some Ada application stores its data in a database. The way the data are
>> organized there is free.
> 
> Its not clear to me what you mean by "free" here.

It means that bindings (the driver) are free to choose the most suitable
implementation. The application describes what it needs and the driver
implements it using available gears. It is not guaranteed that the
schemata, types etc will be same for other data bases or on other
platforms.

>> B. Accessing existing (but unknown at design time) data base. The data
>> structure is fixed and the application must adapt to it.
> 
> I think I know the two points you are raising, but it isn't
> clear which is A or B.
> 
>> A is much easier than B. Not everybody needs B. Further B is often bound to
>> some concrete data base, in which case data base specific bindings make
>> much sense. So we could ignore B for a while. At least until it will be
>> clear how to provide at least A.
> 
> If in one case you mean a package capable of being used in a GUI
> tool, where it can connect to the database and discover tables,
> keys, indexes, views, triggers and the like, and allow dynamic
> operations without any foreknowledge, then agreed, this is much
> more difficult. This is even more of a nightmare approach wise,
> because the standard(s) never addressed this need - hence every
> vendor implements this functionality they way they see fit.

Yes, this would be B.

> While the above is import (for tools), application needs are usually
> much simpler. Written to do fixed operations, on a fixed set of
> tables, views and stored procedures. But as I've pointed out,
> even this simpler case is complex in a multi-vendor world.

I think that static vs. dynamic difference is rather marginal. Essential is
who must adapt to whom, i.e. A vs. B.

>>>Related to this same issue is how to identify rows that lack
>>>a natural primary key. Some databases support an identity
>>>type for the purpose (Sybase), while others use sequences.
>>>Still others like MySQL use some weird idea of an auto
>>>increment integer field (I am too lazy to look up the
>>>specifics for this, but this is documented in the APQ
>>>manual).
>>>
>>>Here's another good one: Some databases allow you to declare
>>>a VARCHAR(256). Others are restricted to VARCHAR(255), and you
>>>must switch to a different type (TEXT I think), if you need
>>>longer fields.
>>>
>>>Some support boolean types, and others do not. Some support
>>>arrays, others do not. If they both support arrays, they
>>>are guaranteed to work with different rules and syntax.
>>>
>>>There seems to be virtually no agreement on how blobs are
>>>handled and managed, between the different products.
>> 
>> This is the case B. 
> 
> Blobs?
>
>>I think that it could still be possible to solve it in
>> an OO way. 
> 
> I beg to differ on this one, though I've not tried very
> hard on this one ;-)  Consider some of the challenges:
> 
> 1) PostgreSQL uses an API that opens/creates etc. and returns
>     an OID.
> 2) PostgreSQL blobs are referenced by saving a OID in a column
>     of a row.
> 3) ALL PostgreSQL blob operations must occur within the confines
>     of a transaction (otherwise the operation fails!)
> 4) MySQL (IIRC), wants you to put the entire blob into a
>     row.
> 5) MySQL, IIRC, wants you to perform the blob I/O in one
>     operation and IIRC, doesn't care about transactions (optional).
> 6) PostgreSQL blobs can be operated on like files, with seeks,
>     partial writes, reads etc.

In the case A it is up to the driver what (and if) it would use for some
given type. The driver of a database X knows how to deal with large
objects. If, say, a Postres driver decides that the type Baz should be
stored as a blob, then it should add all necessary bells and whistles
transparent to the application. Compare: in 99.9% cases I do not care if
and how the Ada compiler creates dopes for my arrays.

Also I wouldn't be much surprised if users of the A-bindings will never
store giant indigestible objects into a data base. It is not the Ada's way,
after all. What is stored as blobs, usually has some finer internal
structure, which appears too complex to map it into data base things.
Provided that this need to be made manually. Being automated via A-bindings
it might turn very different.

> I seem to recall there were more problems, but when I started
> with this list, I decided to leave it for a rainy day!!! ;-)
> 
>> All database types should be derived from one base. Factory can
>> be used to create values "like in the column". Differences between VARCHAR,
>> TEXT, LONGCHAR etc are uninteresting for the application. 
> 
> You might expect so, but the Boolean case and Dates have created
> a lot of problem. Since you have to work with SQL, how do you
> satisfy databases that want 0 and 1 for Booleans (or bit?),
> and the more nomal ones that that True and False?

That would be the case B! For A, the application will just use say
Ada.Database.Relational.Boolean, which the driver will translate into the
most appropriate type for the data base it supports: SMALLINT, CHAR, BIT,
whatsoever available.

> I sheltered the application to some degree from this in APQ,
> but allowing the fields to be encoded for you (APQ knows
> in the MySQL case it wants 0 and 1 - I think it was MySQL).
> But this problem still pokes out in places like hardcoded WHERE
> clauses :
> 
> ...
> WHERE MARRIED = False and ...
> 
> or
> 
> WHERE MARRIED = 0 and ...
> 
> So if MARRIED is BOOLEAN, I think you have to test if you
> are using MySQL (I think it was them), and then use the 0
> and 1 instead (or use APQ to encode a hardcoded False!)
> 
> Dates, Timestamps and timezones get even more interesting.
> Versions of databases add to the problems! MySQL in one
> version formats the dates differently than later versions
> -- ugh!

This is exactly why I would like to get rid of any traces of SQL in the
bindings. The interface should provide an iterator. The iteration filter
will be an object describing the filtering condition. That will be
translated by the driver into SQL's WHERE ... with all literals selected as
required. ODBC does it well for ?-parameters in prepared statements. (SQL
is the evil! (:-))

>> In general I do not think that primitive data types are the greatest
>> problem. The problem is that the semantics of "what and how" slips away. It
>> is too low level.
> 
> I think you would be surprised! Just sticking to "normal"
> primitive data types in APQ, has had me see enough horrors ;-)

I am not. For example with ODBC, you have to ask the driver what it has
today for say GUID. Let it answers: sorry. What would your application do?
Emulate GUID using BIGINT, TIMESTAMP? ODBC is just irreparably wrong!

>>>The list of incompatibilities and differences are many
>>>more. For example, there are differences in the way the
>>>client libraries work (ability to fetch one row at a time,
>>>randomly or not (PostgreSQL), must fetch them all into
>>>client memory for random access, or use one-at-a-time
>>>sequential access (MySQL), etc.)
>>>
>>>The challenges for a "unified Ada access" layer are so
>>>numerous, that I consider it unachievable. I took a stab
>>>at providing a "portable" binding in APQ, but had to
>>>make various compromises along the way (these are documented
>>>in the manual).
>> 
>> I think that APQ could become an alternative to ODBC. ODBC tries to swallow
>> documents and spreadsheets (like Excel), things that are too far from a
>> "normal" data base.
> 
> Well, in fairness to ODBC, some sort of generalized interface
> was called for, and it was "a solution" of sorts. But I never
> felt it was meant to be used by application programmers.

My impression is that ODBC tried to be both A and B, and failed both.

> IMHO,
> any API that has application programmers coding a whole whack
> of complex API calls to just do a select and return a row (for
> example), is not "the solution". Application programmers want
> to focus on the application problem - not API details (most
> mediochre programmers can't get it right anyway). Once coded,
> it becomes so complex, that no one wants to make major changes
> to it. Then comes the patchwork!

Yes

> Many people feel that code generators are the answer. I disagree
> there also. That is a one-time fix. Eventually, someone has to
> go back and change it. At this point it is unreadable and near
> unmaintainable.

Yes

> APQ tries to make it simple for the application programmer. I
> would much rather be thinking in SQL and Ada terms, than trying
> trying to remember API calls. APQ's API tries to be self
> intuitive, and time will tell if it is or not.
> 
> This has been an interesting diversion ;-)

Yes!

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

Re: Windows Ada database support.

[Georg Bauhaus]

Dmitry A. Kazakov <mailbox@dmitry-kazakov.de> wrote:

: I think that this is a shortcoming of the very concept of a relational
: view. Relation is not an array. Period.

Who says that a relation is an array?

: Also we should distinguish two cases:
: 
: A. Some Ada application stores its data in a database. The way the data are
: organized there is free.
: 
: B. Accessing existing (but unknown at design time) data base. The data
: structure is fixed and the application must adapt to it.
: 
: A is much easier than B.

Wow. I wonder what kind of trivial or specialized applications you have in
mind. General purpose databases, of whatever flavor, are complex beasts,
no matter what. A lot has been written about databases, many solutions
have been tried, a lot of research is going on.  No use ignoring all of
it. So far I think you are just repeating the *questions* that have
accompanied the huge database efforts.


-- Georg

Re: Windows Ada database support.

[Dmitry A. Kazakov]

On Tue, 7 Dec 2004 15:49:36 +0000 (UTC), Georg Bauhaus wrote:

> Dmitry A. Kazakov <mailbox@dmitry-kazakov.de> wrote:
> 
>: I think that this is a shortcoming of the very concept of a relational
>: view. Relation is not an array. Period.
> 
> Who says that a relation is an array?

Nobody. The problem is that we need arrays, or more generally, ordered
containers. This is the way the most people think about tables. They do not
think about them in terms of relations. Yes, a relational view is complete
and you can express everything in it. But it is too low level. This is why
people keep on inventing ways to mark that damned rows. Nothing is wrong
with that, but the result is, as Warren has pointed out, utter chaos.

>: Also we should distinguish two cases:
>: 
>: A. Some Ada application stores its data in a database. The way the data are
>: organized there is free.
>: 
>: B. Accessing existing (but unknown at design time) data base. The data
>: structure is fixed and the application must adapt to it.
>: 
>: A is much easier than B.
> 
> Wow. I wonder what kind of trivial or specialized applications you have in
> mind.

Very trivial. I have data, I need to organize and store them.

> General purpose databases, of whatever flavor, are complex beasts,
> no matter what.

Why an application that need to store data, should care about that? Sorry,
I still cannot understand it. Do you care much about ferromagnetism when
you write a file onto the hard drive?

> A lot has been written about databases, many solutions
> have been tried, a lot of research is going on. No use ignoring all of
> it.

Oh, I welcome research, but yes, I keep on trying to ignore that. (:-))

> So far I think you are just repeating the *questions* that have
> accompanied the huge database efforts.

Maybe.

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

Re: Windows Ada database support.

[Georg Bauhaus]

Dmitry A. Kazakov <mailbox@dmitry-kazakov.de> wrote:
: On Tue, 7 Dec 2004 15:49:36 +0000 (UTC), Georg Bauhaus wrote:
: 
:> Dmitry A. Kazakov <mailbox@dmitry-kazakov.de> wrote:
:> 
:>: I think that this is a shortcoming of the very concept of a relational
:>: view. Relation is not an array. Period.
:> 
:> Who says that a relation is an array?
: 
: Nobody. The problem is that we need arrays, or more generally, ordered
: containers. This is the way the most people think about tables.

Hm. If at the DB level you ask,

SELECT S.key, T.foo, T.bar from S, T
WHERE (S.key BETWEEN 100 AND 200)
  AND T.foo = S.key
ORDER BY S.key

Then you have in Ada.Container terms,
   function Floor (Container : Map;
                   Key       : Key_Type) return Cursor;

   function Ceiling (Container : Map;
                     Key       : Key_Type) return Cursor;
where
   S.key >= 100  can be made the floor
and
   S.key <= 200  can be made the ceiling.


: They do not
: think about them in terms of relations.

You mean they do not think about the relations between records,
for example? Well, yes, but how could this be overcome using
another language? A fair amount of referential integrity can
be "extracted" from an ER diagram using standard means. If this
way of defining tables in a database is not standard, do you think
that another standard, Ada, is going to help?


: Why an application that need to store data, should care about that? Sorry,
: I still cannot understand it.

1/ other applications may (have to) modify your data without notice.
3/ storing data might take time. RDB or not, I need to know this
2/ you might need backups and secure storage. This is provided by
   good RDBMSs.

: Do you care much about ferromagnetism when
: you write a file onto the hard drive?

I certainly do. In particular when the disks are 5 years old
and not part of a well maintained RAID. ;-)


-- Georg

Re: Windows Ada database support.

[Dmitry A. Kazakov]

On Wed, 8 Dec 2004 02:24:25 +0000 (UTC), Georg Bauhaus wrote:

> Dmitry A. Kazakov <mailbox@dmitry-kazakov.de> wrote:
>: On Tue, 7 Dec 2004 15:49:36 +0000 (UTC), Georg Bauhaus wrote:
>: 
>:> Dmitry A. Kazakov <mailbox@dmitry-kazakov.de> wrote:
>:> 
>:>: I think that this is a shortcoming of the very concept of a relational
>:>: view. Relation is not an array. Period.
>:> 
>:> Who says that a relation is an array?
>: 
>: Nobody. The problem is that we need arrays, or more generally, ordered
>: containers. This is the way the most people think about tables.
> 
> Hm. If at the DB level you ask,
> 
> SELECT S.key, T.foo, T.bar from S, T
> WHERE (S.key BETWEEN 100 AND 200)
>   AND T.foo = S.key
> ORDER BY S.key

This is the source of the problems in my view. What does SELECT in
application terms? A developer would like to be two storeys above that.

> Then you have in Ada.Container terms,
>    function Floor (Container : Map;
>                    Key       : Key_Type) return Cursor;
> 
>    function Ceiling (Container : Map;
>                      Key       : Key_Type) return Cursor;
> where
>    S.key >= 100  can be made the floor
> and
>    S.key <= 200  can be made the ceiling.

You are thinking in terms of SQL. From this point of view nothing or very
little could be done. And after all, GNADE provides embedded SQL for that
stuff.

>: They do not
>: think about them in terms of relations.
> 
> You mean they do not think about the relations between records,
> for example? Well, yes, but how could this be overcome using
> another language? A fair amount of referential integrity can
> be "extracted" from an ER diagram using standard means. If this
> way of defining tables in a database is not standard, do you think
> that another standard, Ada, is going to help?

It should be an Ada standard, not a DB standard. Does Ada influence any
hardware standards?

>: Why an application that need to store data, should care about that? Sorry,
>: I still cannot understand it.
> 
> 1/ other applications may (have to) modify your data without notice.

These should either use the same bindings or be conform. That's the
requirement of the case A in my classification. When you store a BMP image,
you do not expect to be able to read it as JPEG, right?

> 3/ storing data might take time. RDB or not, I need to know this

If you mean performance, then that's the case with programming in general.
User of any feature should know what is cheap and what is expensive. When
you pass 2MB object by value, you know what to expect. No difference here.

If you mean shared access then the standard should provide mutual exclusion
for critical sections. The implementation may use transactions, file locks,
whatsoever available to achieve exclusion. It is responsibility of the
application to express the exclusion constraints, it is no different from
how we do it when we program tasks.

> 2/ you might need backups and secure storage. This is provided by
>    good RDBMSs.

Same as above.

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

Re: Windows Ada database support.

[Ole-Hjalmar Kristensen]

>>>>> "DAK" == Dmitry A Kazakov <mailbox@dmitry-kazakov.de> writes:

    DAK> On Wed, 8 Dec 2004 02:24:25 +0000 (UTC), Georg Bauhaus wrote:
    >> Dmitry A. Kazakov <mailbox@dmitry-kazakov.de> wrote:
    >> : On Tue, 7 Dec 2004 15:49:36 +0000 (UTC), Georg Bauhaus wrote:
    >> : 
    >> :> Dmitry A. Kazakov <mailbox@dmitry-kazakov.de> wrote:
    >> :> 
    >> :>: I think that this is a shortcoming of the very concept of a relational
    >> :>: view. Relation is not an array. Period.
    >> :> 
    >> :> Who says that a relation is an array?
    >> : 
    >> : Nobody. The problem is that we need arrays, or more generally, ordered
    >> : containers. This is the way the most people think about tables.
    >> 
    >> Hm. If at the DB level you ask,
    >> 
    >> SELECT S.key, T.foo, T.bar from S, T
    >> WHERE (S.key BETWEEN 100 AND 200)
    >> AND T.foo = S.key
    >> ORDER BY S.key

    DAK> This is the source of the problems in my view. What does SELECT in
    DAK> application terms? A developer would like to be two storeys above that.

A good question. But isn't the goal of the application programmer
precisely to select an implementation of the domain-specific concepts?
So the application programmer cannot really be "two storeys above
that", he has to choose how to do the mapping to some more general
representation, be it DB schema or programming language.
An even better question is what do you want to accomplish, in terms of
your *problem* domain? It isn't obvious to me that using another
interface to the DB (object-oriented, navigational, ER-like, etc) in
general will make the mapping from the problem domain any easier. For
many application domains, thinking in terms of sets and relations are
perfectly fine, and going to an object-oriented / navigational model
and effectively doing your own joins isn't going to help you much. You
have to implement the relations between your problem-domain objects in
some way, and the relational model and the use of normailzation has
proven itself to be a very robust and flexible way of doing this,
although not necessarily the most efficient.

If you have a better model for describing the problem domain in mind,
I'm more than willing to listen.

Btw., many years ago I worked on a project where the main goal was to
develop a rapid prototyping tool for DB applications. The project
started because a fellow analyst found out that lots of customers did
not really understand the implications of the ER models he created, so
he felt the need to rapidly create a set of example applications which
could illustrate the possibilities of his ER model.  Our approach was
to first create the ER model, then to create an "application" or form,
we would select some entity as the root. By following the relations
from this root entity we could reach other entities, and so on,
effectively creating a hierarchical structure from the ER network. The
tool also allowed you to select a subset of the attributes for each
entity.  The DB schema was automatically created from the ER model,
and the prototyping tool also generated descriptions of the logic (in
terms of interpreted code and SQL) and a graphical user interface for
each application. The actual execution of the application was done by
an interpreter, in order to give us rapid turnaround time (just
seconds to make changes to your application or schema and try it
again), but of course you could just as well have created data type
definitions and access functions in a compiled language to allow an
application writer easy access to the ER model/DB schema through a set
of application-specific interfaces.

    >> Then you have in Ada.Container terms,
    >> function Floor (Container : Map;
    >> Key       : Key_Type) return Cursor;
    >> 
    >> function Ceiling (Container : Map;
    >> Key       : Key_Type) return Cursor;
    >> where
    >> S.key >= 100  can be made the floor
    >> and
    >> S.key <= 200  can be made the ceiling.

    DAK> You are thinking in terms of SQL. From this point of view nothing or very
    DAK> little could be done. And after all, GNADE provides embedded SQL for that
    DAK> stuff.

He may just as well be thinking in terms of sets and relations. SQL is
just a slightly clumsy way of conveying those thoughts to the DB
engine :-)

<snip>

-- 
   C++: The power, elegance and simplicity of a hand grenade.

Re: Windows Ada database support.

[Dmitry A. Kazakov]

On 08 Dec 2004 11:03:44 +0100, Ole-Hjalmar Kristensen wrote:

>>>>>> "DAK" == Dmitry A Kazakov <mailbox@dmitry-kazakov.de> writes:
> 
>     DAK> On Wed, 8 Dec 2004 02:24:25 +0000 (UTC), Georg Bauhaus wrote:
>     >> Dmitry A. Kazakov <mailbox@dmitry-kazakov.de> wrote:
>     >> : On Tue, 7 Dec 2004 15:49:36 +0000 (UTC), Georg Bauhaus wrote:
>     >> : 
>     >> :> Dmitry A. Kazakov <mailbox@dmitry-kazakov.de> wrote:
>     >> :> 
>     >> :>: I think that this is a shortcoming of the very concept of a relational
>     >> :>: view. Relation is not an array. Period.
>     >> :> 
>     >> :> Who says that a relation is an array?
>     >> : 
>     >> : Nobody. The problem is that we need arrays, or more generally, ordered
>     >> : containers. This is the way the most people think about tables.
>     >> 
>     >> Hm. If at the DB level you ask,
>     >> 
>     >> SELECT S.key, T.foo, T.bar from S, T
>     >> WHERE (S.key BETWEEN 100 AND 200)
>     >> AND T.foo = S.key
>     >> ORDER BY S.key
> 
>     DAK> This is the source of the problems in my view. What does SELECT in
>     DAK> application terms? A developer would like to be two storeys above that.
> 
> A good question. But isn't the goal of the application programmer
> precisely to select an implementation of the domain-specific concepts?

Yes, but from one storey below! (:-)) It is essential not to sink in
details.

> So the application programmer cannot really be "two storeys above
> that", he has to choose how to do the mapping to some more general
> representation, be it DB schema or programming language.
> An even better question is what do you want to accomplish, in terms of
> your *problem* domain? It isn't obvious to me that using another
> interface to the DB (object-oriented, navigational, ER-like, etc) in
> general will make the mapping from the problem domain any easier.

So the point is that SQL is the best thing one can imagine? George's point
was, in my interpretation:

SQL is an inevitable evil (mostly because of performance requirements),
higher abstraction is impossible.

Your point seems to be:

Higher abstraction isn't even needed because SQL is the ultimate optimum.

> For
> many application domains, thinking in terms of sets and relations are
> perfectly fine, and going to an object-oriented / navigational model
> and effectively doing your own joins isn't going to help you much.

Again, there are two different questions. I have already formulated them in
another post:

1. Why relations should be handled?
2. Why Ada cannot handle them?

To dismiss Ada.Database.Relational, we have to answer 1=yes, 2=no,
because...

Note I do not argue that 1=no. I only suspect that there might be better
ways. But let's agree for a moment that 1=*YES*. Then, what about 2?

> You
> have to implement the relations between your problem-domain objects in
> some way, and the relational model and the use of normailzation has
> proven itself to be a very robust and flexible way of doing this,
> although not necessarily the most efficient.
> 
> If you have a better model for describing the problem domain in mind,
> I'm more than willing to listen.

OK, you wished that! (:-)) I would like to view it as a distributed system
and get rid of the notion of DB altogether. Only persistent objects. No
I/O, just memory-mappings. [ Clearly, in any short term perspective it is
an utopia. ]

> Btw., many years ago I worked on a project where the main goal was to
> develop a rapid prototyping tool for DB applications. The project
> started because a fellow analyst found out that lots of customers did
> not really understand the implications of the ER models he created, so
> he felt the need to rapidly create a set of example applications which
> could illustrate the possibilities of his ER model.  Our approach was
> to first create the ER model, then to create an "application" or form,
> we would select some entity as the root. By following the relations
> from this root entity we could reach other entities, and so on,
> effectively creating a hierarchical structure from the ER network. The
> tool also allowed you to select a subset of the attributes for each
> entity.

Nice.

> The DB schema was automatically created from the ER model,
> and the prototyping tool also generated descriptions of the logic (in
> terms of interpreted code and SQL) and a graphical user interface for
> each application. The actual execution of the application was done by
> an interpreter, in order to give us rapid turnaround time (just
> seconds to make changes to your application or schema and try it
> again), but of course you could just as well have created data type
> definitions and access functions in a compiled language to allow an
> application writer easy access to the ER model/DB schema through a set
> of application-specific interfaces.

Excellent. Why something like that cannot become Ada.Databases?

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

Re: Windows Ada database support.

[Marius Amado Alves]

> ... I would like to view it as a distributed system
> and get rid of the notion of DB altogether. Only persistent objects. No
> I/O, just memory-mappings. [ Clearly, in any short term perspective it is
> an utopia. ] (Kasakov)

Utopia? There are currently persistent and prevalent object systems for 
Ada and Java and probably other languages. I recall Prevayler for Java, 
and at least one persistent system for Ada (isn't that actually by 
yourself?). The problem is they force an object oriented model which as 
has been argued does not always fit the application domain well.

Re: Windows Ada database support.

[Frank Piron]

Am Wed, 08 Dec 2004 11:19:02 +0000 schrieb Marius Amado Alves 
<amado.alves@netcabo.pt>:

>> ... I would like to view it as a distributed system
>> and get rid of the notion of DB altogether. Only persistent objects. No
>> I/O, just memory-mappings. [ Clearly, in any short term perspective it 
>> is
>> an utopia. ] (Kasakov)
>
> Utopia? There are currently persistent and prevalent object systems for 
> Ada and Java and probably other languages. I recall Prevayler for Java, 
> and at least one persistent system for Ada (isn't that actually by 
> yourself?). The problem is they force an object oriented model which as 
> has been argued does not always fit the application domain well.
>
In a past project i considered Cachￜ as an alternative to pure relational
databases (see http://www.intersystems.com/cache/technology/index.html).
I discussed the possibility of writing an Ada Binding to Cachￜ with
consultants from Intersystems. They seemed to be interested, but then on
a customer demand we were forced to choose big O.
-- 
Frank Piron,
defrankatkonaddot
(leftrotate two)

Re: Windows Ada database support.

[Dmitry A. Kazakov]

On Wed, 08 Dec 2004 11:19:02 +0000, Marius Amado Alves wrote:

>> ... I would like to view it as a distributed system
>> and get rid of the notion of DB altogether. Only persistent objects. No
>> I/O, just memory-mappings. [ Clearly, in any short term perspective it is
>> an utopia. ] (Kasakov)
> 
> Utopia? There are currently persistent and prevalent object systems for 
> Ada and Java and probably other languages. I recall Prevayler for Java, 
> and at least one persistent system for Ada (isn't that actually by 
> yourself?).

Yes. But I meant a distributed system. Object persistence alone is not
enough for a great number of applications. Translated into DB terms: a
distributed system is when you have stored procedures. Just persistence
means that you read object(s), process them locally and then store back.

> The problem is they force an object oriented model which as 
> has been argued does not always fit the application domain well.

Why should it be any problem? Considering OO as an advanced ADT, I see no
clear alternative. If you mean that established OO religion, well, that is
not a technical issue.

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

Re: Windows Ada database support.

[Dmitry A. Kazakov]

On Wed, 08 Dec 2004 13:51:12 +0100, Frank Piron wrote:

> In a past project i considered Cach� as an alternative to pure relational
> databases (see http://www.intersystems.com/cache/technology/index.html).

Interesting. Thanks for the link!

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

Re: Windows Ada database support.

[Georg Bauhaus]

Ole-Hjalmar Kristensen <ole-hjalmar.kristensen@substitute_employer_here.com> wrote:
: He may just as well be thinking in terms of sets and relations. SQL is
: just a slightly clumsy way of conveying those thoughts to the DB
: engine :-)

Yes, thanks. I was thinking about one of those tiny little
everyday problems, and how to solve it and how to employ Ada
.Containers as "middleware". The problem:

 "Declare an ordered selection of objects. Make it available"

Objects may be either just fetched from the DB or they may be synthesized,
i.e. newly constructed from the DB (!), effectively establishing a type.
If a language supports EVAL, you can even construct the types at
at language level at run time.

Omitting the ordering issue, a SETL2 expression demonstrates a
non-SQL solution:

  result := { [foo, bar] :
     id in { R.key : R in S | R.key >= 100 and R.key <= 200 },
        bar = T(foo) | foo = id };

No trace of SQL, but I'm sure you can see the relation between
a SET programming language and SQL. Note the result set ;-)
This is working code, S and T are sets of tuples.
You may say that there are tuples and sets, iieek. But the in
computer programs you will have to work with some sort of
compound data at some level.
If you dislike the presence of tuples, ".key" is a selector.
R.key means the same as R(1).  This allows you to build interfaces
so you don't have to see the tuples.

Dmitry, what is your plan the other way round, i.e. how do you
make data related expressions for some nice higher level abstraction?


-- Georg

Re: Windows Ada database support.

[Georg Bauhaus]

Dmitry A. Kazakov <mailbox@dmitry-kazakov.de> wrote:
: Again, there are two different questions. I have already formulated them in
: another post:
: 
: 1. Why relations should be handled?
: 2. Why Ada cannot handle them?
: 
: To dismiss Ada.Database.Relational, we have to answer 1=yes, 2=no,
: because...

Ada the language does not have what SQL processors do have.
You would have to build some sort of DKQL processor in your
Ada.Databases.Relational. Go ahead :-)
 

: I would like to view it as a distributed system
: and get rid of the notion of DB altogether. Only persistent objects. No
: I/O, just memory-mappings. [ Clearly, in any short term perspective it is
: an utopia. ]

Say all you have is persistent objects. What kind of query do you
have if you want to know about 2 or more objects?

Re: Windows Ada database support.

[Georg Bauhaus]

Dmitry A. Kazakov <mailbox@dmitry-kazakov.de> wrote:
 
: Yes. But I meant a distributed system. Object persistence alone is not
: enough for a great number of applications. Translated into DB terms: a
: distributed system is when you have stored procedures.

I think few people will agree here. A DBMS is usually serving your
distributed program, and also several different, possibly unrelated
distributed programs. Stored procedures need not even be present.
There might be good organisational reasons to use a common DB for
the different programs.

I think that "coordinating I/O" in the way of a DBMS is rather tricky.
Do you have an idea of a protocol that might extend Ada's rudimentary
distribution support to achieve at least as much data coordination
as contemporary DBMSs?


-- Georg

Re: Windows Ada database support.

[Dmitry A. Kazakov]

On Wed, 8 Dec 2004 15:58:44 +0000 (UTC), Georg Bauhaus wrote:

> Dmitry A. Kazakov <mailbox@dmitry-kazakov.de> wrote:
>: Again, there are two different questions. I have already formulated them in
>: another post:
>: 
>: 1. Why relations should be handled?
>: 2. Why Ada cannot handle them?
>: 
>: To dismiss Ada.Database.Relational, we have to answer 1=yes, 2=no,
>: because...
> 
> Ada the language does not have what SQL processors do have.

But you can translate into SQL. Why Ada.Database.Relational.Foo cannot call
My_ Fancy_DB.Execute ("BAZ ...")? I do not propose to write a new DB
engine.

> You would have to build some sort of DKQL processor in your
> Ada.Databases.Relational. Go ahead :-)

>: I would like to view it as a distributed system
>: and get rid of the notion of DB altogether. Only persistent objects. No
>: I/O, just memory-mappings. [ Clearly, in any short term perspective it is
>: an utopia. ]
> 
> Say all you have is persistent objects. What kind of query do you
> have if you want to know about 2 or more objects?

Why should I query? It is for untyped tables. If I have an object at hand
then I know its type and so everything I can do with it. If I don't, then I
have another object, a container that refers to my object. That container
again has a type and that provides operations to access its elements.

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

Re: Windows Ada database support.

[Dmitry A. Kazakov]

On Wed, 8 Dec 2004 16:09:01 +0000 (UTC), Georg Bauhaus wrote:

> Dmitry A. Kazakov <mailbox@dmitry-kazakov.de> wrote:
>  
>: Yes. But I meant a distributed system. Object persistence alone is not
>: enough for a great number of applications. Translated into DB terms: a
>: distributed system is when you have stored procedures.
> 
> I think few people will agree here. A DBMS is usually serving your
> distributed program, and also several different, possibly unrelated
> distributed programs.
>
> Stored procedures need not even be present.
> There might be good organisational reasons to use a common DB for
> the different programs.

Yes of course. Programs coupled via DB can be viewed as a primitive
distributed application. Stored procedures were a more shiny example.

> I think that "coordinating I/O" in the way of a DBMS is rather tricky.
> Do you have an idea of a protocol that might extend Ada's rudimentary
> distribution support to achieve at least as much data coordination
> as contemporary DBMSs?

We have tasks and protected objects. Add here marshaling parameters. So you
will need by-value semantics for types of those. Hence, allow T'Class for
everything. You will then need interface inheritance from concrete types
(to have automatic user-defined type conversions between local and remote
types). That drags MI. Do not forget to make tasks and protected objects
OO. Something like COM/DCOM will be also very useful...

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

Re: Windows Ada database support.

[Dmitry A. Kazakov]

On Wed, 8 Dec 2004 15:52:17 +0000 (UTC), Georg Bauhaus wrote:

> Ole-Hjalmar Kristensen <ole-hjalmar.kristensen@substitute_employer_here.com> wrote:
>: He may just as well be thinking in terms of sets and relations. SQL is
>: just a slightly clumsy way of conveying those thoughts to the DB
>: engine :-)
> 
> Yes, thanks. I was thinking about one of those tiny little
> everyday problems, and how to solve it and how to employ Ada
> .Containers as "middleware". The problem:
> 
>  "Declare an ordered selection of objects. Make it available"
> 
> Objects may be either just fetched from the DB or they may be synthesized,
> i.e. newly constructed from the DB (!), effectively establishing a type.
> If a language supports EVAL, you can even construct the types at
> at language level at run time.
> 
> Omitting the ordering issue, a SETL2 expression demonstrates a
> non-SQL solution:
> 
>   result := { [foo, bar] :
>      id in { R.key : R in S | R.key >= 100 and R.key <= 200 },
>         bar = T(foo) | foo = id };
> 
> No trace of SQL, but I'm sure you can see the relation between
> a SET programming language and SQL. Note the result set ;-)
> This is working code, S and T are sets of tuples.
> You may say that there are tuples and sets, iieek. But the in
> computer programs you will have to work with some sort of
> compound data at some level.
> If you dislike the presence of tuples, ".key" is a selector.
> R.key means the same as R(1).  This allows you to build interfaces
> so you don't have to see the tuples.
> 
> Dmitry, what is your plan the other way round, i.e. how do you
> make data related expressions for some nice higher level abstraction?

You have cunningly formulated the problem so that there is no higher level!
(:-)) There is either:

for I in S'Range loop
   if S (I).Key in 100..200 then
      for J in T'Range loop
         if T (J).Foo = S (I).Key then
            Append (Result, S (I).Key, T (J).Foo);
         end if;
      end loop;
   end if;
end loop;

or you define "*" (product) for the type Table'Class (of S and T) + other
operations to extract sets from the tables.

But the question is why an application should always organize its data in a
way which could require implementation these, very expensive, operations?
Isn't it so that tabular view just forces global container operations? When
we write in Ada we avoid global operations. How often you copy an array in
Ada (except String<->Unbounded_String conversion (:-))? Merge two arrays?
Isn't S and T just a two-dimensional array?

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

Re: Windows Ada database support.

[Georg Bauhaus]

Dmitry A. Kazakov <mailbox@dmitry-kazakov.de> wrote:
: 
: But you can translate into SQL. Why Ada.Database.Relational.Foo cannot call
: My_ Fancy_DB.Execute ("BAZ ...")? I do not propose to write a new DB
: engine.

This brings us back to the original questions :-)

: Why should I query? It is for untyped tables. If I have an object at hand
: then I know its type and so everything I can do with it. If I don't, then I
: have another object, a container that refers to my object. That container
: again has a type and that provides operations to access its elements.

Relations. Records In DB system, as well as records in Ada have components
which can be updated.  Relations between 2 or more objects may thus depend
on time.  However, an object's type cannot reflect this, because types
are static.  You could associate one different type with each possible
combination of component values in your program...

Re: Windows Ada database support.

[Georg Bauhaus]

Dmitry A. Kazakov <mailbox@dmitry-kazakov.de> wrote:
: On Wed, 8 Dec 2004 15:52:17 +0000 (UTC), Georg Bauhaus wrote:
:> Dmitry, what is your plan the other way round, i.e. how do you
:> make data related expressions for some nice higher level abstraction?
: 
: You have cunningly formulated the problem so that there is no higher level!
: (:-)) There is either:

I think you can go to a higher level. At a cost.

: for I in S'Range loop
:   if S (I).Key in 100..200 then
:      for J in T'Range loop
:         if T (J).Foo = S (I).Key then
:            Append (Result, S (I).Key, T (J).Foo);
:         end if;
:      end loop;
:   end if;
: end loop;
: 
: or you define "*" (product) for the type Table'Class (of S and T) + other
: operations to extract sets from the tables.
: 
: But the question is why an application should always organize its data in a
: way which could require implementation these, very expensive, operations?

First, the operations need not be expensive, e.g. because there is
an index.
Second, when defining the data format, I may not be in a position to
choose freely.  A definition that suits my program might be a real obstacle
to someone else's.

: Isn't S and T just a two-dimensional array?

No, S and T are selections from views. It is up to the RDBMS to organize
the data to fit the SELECTion choices.
Each record in S or T is part of a list of structured values,
each component being of some type. Depending on the DB system, you
might even have more than sequential access prior to turning the
result into an Ada object. 

Re: Windows Ada database support.

[Georg Bauhaus]

Dmitry A. Kazakov <mailbox@dmitry-kazakov.de> wrote:
: We have tasks and protected objects. Add here marshaling parameters. So you
: will need by-value semantics for types of those. Hence, allow T'Class for
: everything. You will then need interface inheritance from concrete types
: (to have automatic user-defined type conversions between local and remote
: types). That drags MI. Do not forget to make tasks and protected objects
: OO. Something like COM/DCOM will be also very useful...

And you end up with the problems of value copying (and externally stored
data). Have a lookt at purely functional programs. :-) Time, memory,
updates, and concurrent updates, are not your friend when you prefer
good abstractions :-)

-- Georg

Re: Windows Ada database support.

[Ole-Hjalmar Kristensen]

>>>>> "DAK" == Dmitry A Kazakov <mailbox@dmitry-kazakov.de> writes:

<snip>

    >> 
    >> Dmitry, what is your plan the other way round, i.e. how do you
    >> make data related expressions for some nice higher level abstraction?

    DAK> You have cunningly formulated the problem so that there is no higher level!
    DAK> (:-)) There is either:

    DAK> for I in S'Range loop
    DAK>    if S (I).Key in 100..200 then
    DAK>       for J in T'Range loop
    DAK>          if T (J).Foo = S (I).Key then
    DAK>             Append (Result, S (I).Key, T (J).Foo);
    DAK>          end if;
    DAK>       end loop;
    DAK>    end if;
    DAK> end loop;

    DAK> or you define "*" (product) for the type Table'Class (of S and T) + other
    DAK> operations to extract sets from the tables.

    DAK> But the question is why an application should always organize its data in a
    DAK> way which could require implementation these, very expensive, operations?
    DAK> Isn't it so that tabular view just forces global container operations? When
    DAK> we write in Ada we avoid global operations. How often you copy an array in
    DAK> Ada (except String<->Unbounded_String conversion (:-))? Merge two arrays?
    DAK> Isn't S and T just a two-dimensional array?

Yes, and you have generic tools to follow relations (join). But There
*are* reasons for organizing your data this way *in the database*.
This organization is very flexible, but as you observe, may be
expensive. SQL compilers have do do lots of optimizations to allow
efficient execution of complex queries, especially since a large
database is orders of magnitude bigger than the amount of available
memory. The basic idea is that you organize your data in a way that
captures the aspects that are inherent to the data domain itself, not
specific to any particular application. This data model (the
conceptual schema) can then support a very large set of different
applications with no need to reorganize the data model. This is much
more flexible than the old network databases, where the access paths
(indices, pointers) were hard-coded into the data model, giving
excellent performance for some applications, and absolutely abysmal
for others, in addition to being hard to maintain. In the three-schema
architecture, each different application is then supported by a
different external schema, typically a subset or a transformation of
the conceptual schema. The application itself need not organize its
internal structures as tables, but having a sound conceptual view and
a normalized structure is really a necessity if your database is going
to support a multitude of applications. This line of thinking
obviously originates from corporate databases and the like, where
there is a need to maintain a large body of data *independently* of
the applications which may happen to use them. I think you see the
similarites between the three-schema architecture and the rapid
prototyping tool I described earlier. It is not a coincidence :-)

Now think of this: *IF* set operations were supported by the
programming language, wouldn't it be a convenient way of structuring
your code (efficiency considerations aside)? Example: I want to update
the salaries of all employees with a specific manager, or I want to
see which projects an employee has worked on in the last month, or
find the sum of all hours employees working for a specific manager has
worked on a specific project. These are all problems which can be
trivially solved using sets. No navigation or hard-coded links
necessary, no need to create objects which maintain the relation
links, no need to add new classes when you want to add a new relation
between objects or when your relation changes from on-to-one to
one-to-many or many-to many. This is taken care of by modyfying the
integrity constraints of your schema. The inherent relations in your
problem remains the same whether you prefer a solution with explicit
links (the most typical for object-oriented solutions, in my
experience), or a tabular organization, in which case you will most
likely use the DBMS engine to do the bulk of the processing. One way
of looking at the difference is that with a tabular organization the
application is free (via set operations) to follow or update any
thinkable relation, limited only by the integrity constraints, while
in an object-oriented or network system, you will typically have
materialized those relations you are interested in, and the
constraints are implicit in your materialization. 

But there clearly is a mismatch between the facilites provided by the
RDBMS and your typical programming language, I am just unsure what is
the best way to bridge that gap.

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

-- 
   C++: The power, elegance and simplicity of a hand grenade.

Re: Windows Ada database support.

[Dmitry A. Kazakov]

On Thu, 9 Dec 2004 12:20:38 +0000 (UTC), Georg Bauhaus wrote:

> Dmitry A. Kazakov <mailbox@dmitry-kazakov.de> wrote:

>: We have tasks and protected objects. Add here marshaling parameters. So you
>: will need by-value semantics for types of those. Hence, allow T'Class for
>: everything. You will then need interface inheritance from concrete types
>: (to have automatic user-defined type conversions between local and remote
>: types). That drags MI. Do not forget to make tasks and protected objects
>: OO. Something like COM/DCOM will be also very useful...
> 
> And you end up with the problems of value copying (and externally stored
> data).

First, they are *not* stored. They exist. Second, it is impossible to have
referential semantics for everything, just because reference itself has to
be by-copy.

> Have a lookt at purely functional programs. :-) Time, memory,
> updates, and concurrent updates, are not your friend when you prefer
> good abstractions :-)

I didn't mean that. Yes we have to marshal the parameters. But it by no
means imply that we should marshal everything. It is up to the application
to decide what should be passed by-copy and what by-reference (handle). It
is no different from what happens when you compile a procedure call in Ada.
Protected objects are by-reference in Ada. The difference though is that in
a distributed application physical location of an object may change. So the
run-time should be able to move an object from one place to another, to
make a replica of it etc.

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

Re: Windows Ada database support.

[Dmitry A. Kazakov]

On Thu, 9 Dec 2004 12:12:22 +0000 (UTC), Georg Bauhaus wrote:

[...]

> First, the operations need not be expensive, e.g. because there is
> an index.

Global operations are always expensive.

> Second, when defining the data format, I may not be in a position to
> choose freely. A definition that suits my program might be a real obstacle
> to someone else's.

It is simpler: there is no data without operations. When you define
something as a table of rows and columns you also implicitly define the
operations. And these are that real obstacle, in so many cases.

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

Re: Windows Ada database support.

[Dmitry A. Kazakov]

On Thu, 9 Dec 2004 11:58:06 +0000 (UTC), Georg Bauhaus wrote:

> Dmitry A. Kazakov <mailbox@dmitry-kazakov.de> wrote:
>: 
>: But you can translate into SQL. Why Ada.Database.Relational.Foo cannot call
>: My_ Fancy_DB.Execute ("BAZ ...")? I do not propose to write a new DB
>: engine.
> 
> This brings us back to the original questions :-)
> 
>: Why should I query? It is for untyped tables. If I have an object at hand
>: then I know its type and so everything I can do with it. If I don't, then I
>: have another object, a container that refers to my object. That container
>: again has a type and that provides operations to access its elements.
> 
> Relations. Records In DB system, as well as records in Ada have components
> which can be updated.  Relations between 2 or more objects may thus depend
> on time.

= bad design, if you are you talking about changes unknown during design.
In that case you are in trouble anyway! You have to modify all UPDATE
statements if just a new column is added. Consider a memory snapshot made
before changing the CPU from Intel to PowerPC. This is what your DB is
worth. You can still read and write it. But data without semantics is a
garbage.

But if my language supports interface inheritance I can still deal with
reasonable changes. I could derive new types from old bases and throw out
old representations:

type X is record
   Foo : Integer;
   Bar : String (...)
end record;

type Y is new X without Foo -- (:-))
   with record
      Baz : Float;
   end record;  

Of course the compiler will force me to define getter and setter for Y.Foo,
otherwise all class-wide methods will be lost.

> However, an object's type cannot reflect this, because types
> are static.  You could associate one different type with each possible
> combination of component values in your program...

1. No application uses all possible combinations. They have very concrete
things to do.

2. Types are static but values are not. This is why T'Class works so
nicely!

3. Remember, I always campaigned for MI and MD in comp.lang.ada! (:-))

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

Re: Windows Ada database support.

[Dmitry A. Kazakov]

On 09 Dec 2004 13:22:15 +0100, Ole-Hjalmar Kristensen wrote:

>>>>>> "DAK" == Dmitry A Kazakov <mailbox@dmitry-kazakov.de> writes:
> 
> <snip>
>     >> 
>     >> Dmitry, what is your plan the other way round, i.e. how do you
>     >> make data related expressions for some nice higher level abstraction?
> 
>     DAK> You have cunningly formulated the problem so that there is no higher level!
>     DAK> (:-)) There is either:
> 
>     DAK> for I in S'Range loop
>     DAK>    if S (I).Key in 100..200 then
>     DAK>       for J in T'Range loop
>     DAK>          if T (J).Foo = S (I).Key then
>     DAK>             Append (Result, S (I).Key, T (J).Foo);
>     DAK>          end if;
>     DAK>       end loop;
>     DAK>    end if;
>     DAK> end loop;
> 
>     DAK> or you define "*" (product) for the type Table'Class (of S and T) + other
>     DAK> operations to extract sets from the tables.
> 
>     DAK> But the question is why an application should always organize its data in a
>     DAK> way which could require implementation these, very expensive, operations?
>     DAK> Isn't it so that tabular view just forces global container operations? When
>     DAK> we write in Ada we avoid global operations. How often you copy an array in
>     DAK> Ada (except String<->Unbounded_String conversion (:-))? Merge two arrays?
>     DAK> Isn't S and T just a two-dimensional array?
> 
> Yes, and you have generic tools to follow relations (join). But There
> *are* reasons for organizing your data this way *in the database*.
> This organization is very flexible, but as you observe, may be
> expensive. SQL compilers have do do lots of optimizations to allow
> efficient execution of complex queries, especially since a large
> database is orders of magnitude bigger than the amount of available
> memory. The basic idea is that you organize your data in a way that
> captures the aspects that are inherent to the data domain itself, not
> specific to any particular application. This data model (the
> conceptual schema) can then support a very large set of different
> applications with no need to reorganize the data model. This is much
> more flexible than the old network databases, where the access paths
> (indices, pointers) were hard-coded into the data model, giving
> excellent performance for some applications, and absolutely abysmal
> for others, in addition to being hard to maintain. In the three-schema
> architecture, each different application is then supported by a
> different external schema, typically a subset or a transformation of
> the conceptual schema. The application itself need not organize its
> internal structures as tables, but having a sound conceptual view and
> a normalized structure is really a necessity if your database is going
> to support a multitude of applications. This line of thinking
> obviously originates from corporate databases and the like, where
> there is a need to maintain a large body of data *independently* of
> the applications which may happen to use them.

Right. They have a giant garbage container and just throw everything in.
The applications have to sort out. (:-)) This approach is efficient no
longer the variety of applications remains very limited. What does anything
just a bit more complex than a business application? It packs everything in
blobs!

> I think you see the
> similarites between the three-schema architecture and the rapid
> prototyping tool I described earlier. It is not a coincidence :-)
> 
> Now think of this: *IF* set operations were supported by the
> programming language, wouldn't it be a convenient way of structuring
> your code (efficiency considerations aside)? Example: I want to update
> the salaries of all employees with a specific manager, or I want to
> see which projects an employee has worked on in the last month, or
> find the sum of all hours employees working for a specific manager has
> worked on a specific project. These are all problems which can be
> trivially solved using sets. No navigation or hard-coded links
> necessary, no need to create objects which maintain the relation
> links, no need to add new classes when you want to add a new relation
> between objects or when your relation changes from on-to-one to
> one-to-many or many-to many. This is taken care of by modyfying the
> integrity constraints of your schema. The inherent relations in your
> problem remains the same whether you prefer a solution with explicit
> links (the most typical for object-oriented solutions, in my
> experience), or a tabular organization, in which case you will most
> likely use the DBMS engine to do the bulk of the processing. One way
> of looking at the difference is that with a tabular organization the
> application is free (via set operations) to follow or update any
> thinkable relation, limited only by the integrity constraints, while
> in an object-oriented or network system, you will typically have
> materialized those relations you are interested in, and the
> constraints are implicit in your materialization. 

True. But also, nothing prevents us (with MI) from providing a relational
view for containers. Comparison with Ada: the major problem with
Unbounded_String is that it does not implement the abstract array
interface. This prevents us from writing generic applications working for
both String and Unbounded_String.

Probably there is no ideal interface for all cases. But OO (or ADT) design
could simultaneously provide support for many views. It seems that vendors
of non-relational data bases have no great problems with implementing SQL
and ODBC for their products.

> But there clearly is a mismatch between the facilites provided by the
> RDBMS and your typical programming language, I am just unsure what is
> the best way to bridge that gap.

To take a look at the calendar! (:-))

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

Re: Windows Ada database support.

[Georg Bauhaus]

Dmitry A. Kazakov <mailbox@dmitry-kazakov.de> wrote:
 
: It is simpler: there is no data without operations. When you define
: something as a table of rows and columns you also implicitly define the
: operations. And these are that real obstacle, in so many cases.

A relational model is also an obstacle to the building of
a distributed non-standard multiple interface multiple dispatch
nightmare :-)
As Ole-Hjalmar has explained, a relational database is middle
ground, you have something standardised with wich others
can work, too.
Imagine IDL and proxies as an alternative. Data exists, but which
part of the ORBA application takes care maintaining its existence?

Incidentally, SETL2, a set language, is said to have a tranparent
database backend (proprietary), so data exists. Also between program
runs.


-- Georg

Re: Windows Ada database support.

[Georg Bauhaus]

Dmitry A. Kazakov <mailbox@dmitry-kazakov.de> wrote:
 

: You have to modify all UPDATE
: statements if just a new column is added.

Nope.

: But data without semantics is a
: garbage.

Data with fixed semantics is inflexible :-)

: 
: I could derive new types from old bases and throw out
: old representations:

unless they carry some important information from the old design
still needed in other applications.

 
:> However, an object's type cannot reflect this, because types
:> are static.  You could associate one different type with each possible
:> combination of component values in your program...
: 
: 1. No application uses all possible combinations. They have very concrete
: things to do.

For example, they react to different value that an object has in time?

 

Re: Windows Ada database support.

[Dmitry A. Kazakov]

On Thu, 9 Dec 2004 18:58:45 +0000 (UTC), Georg Bauhaus wrote:

> Dmitry A. Kazakov <mailbox@dmitry-kazakov.de> wrote:
>  
>: You have to modify all UPDATE
>: statements if just a new column is added.
> 
> Nope.

>: But data without semantics is a
>: garbage.
> 
> Data with fixed semantics is inflexible :-)

Flexible garbage is still garbage. Honestly, I prefer rigid garbage, it is
predictable. Who knows where a flexible one might leak into! (:-))

>: I could derive new types from old bases and throw out
>: old representations:
> 
> unless they carry some important information from the old design
> still needed in other applications.

No, I can always do it as long as the new implementation is conform to the
semantics of T'Class.

>:> However, an object's type cannot reflect this, because types
>:> are static.  You could associate one different type with each possible
>:> combination of component values in your program...
>: 
>: 1. No application uses all possible combinations. They have very concrete
>: things to do.
> 
> For example, they react to different value that an object has in time?

Where is any problem? Doesn't sin(x) react to any value of x whenever it be
called?

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

Re: Windows Ada database support.

[Georg Bauhaus]

Dmitry A. Kazakov <mailbox@dmitry-kazakov.de> wrote:
:>:> However, an object's type cannot reflect this, because types
:>:> are static.  You could associate one different type with each possible
:>:> combination of component values in your program...
:>: 
:>: 1. No application uses all possible combinations. They have very concrete
:>: things to do.
:> 
:> For example, they react to different value that an object has in time?
: 
: Where is any problem? Doesn't sin(x) react to any value of x whenever it be
: called?

if sin(x) > threshold then
 ...

That is, a program doesn't express all possible flows in the set of type
declarations.
Similarly, when programs construct values from standardised "garbage
databases", they express some flows using query results, not necessarily
a style of writing close to the type system.
Moreover, future behavior of the program will be influenced
by manipulating the "garbage database". This feels somewhat like symbol
manipulation  ;-)

Re: Windows Ada database support.

[Dmitry A. Kazakov]

On Fri, 10 Dec 2004 14:28:52 +0000 (UTC), Georg Bauhaus wrote:

> Dmitry A. Kazakov <mailbox@dmitry-kazakov.de> wrote:
>:>:> However, an object's type cannot reflect this, because types
>:>:> are static.  You could associate one different type with each possible
>:>:> combination of component values in your program...
>:>: 
>:>: 1. No application uses all possible combinations. They have very concrete
>:>: things to do.
>:> 
>:> For example, they react to different value that an object has in time?
>: 
>: Where is any problem? Doesn't sin(x) react to any value of x whenever it be
>: called?
> 
> if sin(x) > threshold then
>  ...
> 
> That is, a program doesn't express all possible flows in the set of type
> declarations.
> Similarly, when programs construct values from standardised "garbage
> databases", they express some flows using query results, not necessarily
> a style of writing close to the type system.

Nobody requires to express all semantics in type relations. [Yet compare
how "relationists" are trying to force semantics into relations!]

The known to be stable part of the semantics should be mapped into types.
That is the stand point of strongly, manifestly typed languages like Ada.
Because for practically any application, there is such stable part, and it
is reasonable large. If you will try to convince me that business
applications cannot be programmed in that way, then well, we should agree
that we disagree.

> Moreover, future behavior of the program will be influenced
> by manipulating the "garbage database". This feels somewhat like symbol
> manipulation  ;-)

This is just plainly wrong design. Note that even Ada compiler need not to
translate itself together with the program code. The very fact that Ada
compilers were successfully written in Ada shows that strong typing is no
obstacle.

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

Re: Windows Ada database support.

[Simon Wright]

"Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> writes:

> Nobody. The problem is that we need arrays, or more generally, ordered
> containers. This is the way the most people think about tables. They do not
> think about them in terms of relations. Yes, a relational view is complete
> and you can express everything in it. But it is too low level. This is why
                                                  ^^^^^^^^^^^^^
                                                 too high level, I think!

> people keep on inventing ways to mark that damned rows. Nothing is wrong
> with that, but the result is, as Warren has pointed out, utter chaos.

-- 
Simon Wright                               100% Ada, no bugs.