Version 1.2 of acs/ac-00097.txt

Unformatted version of acs/ac-00097.txt version 1.2
Other versions for file acs/ac-00097.txt

!standard A.01          04-04-23 AC95-00097/01
!class amendment 04-04-23
!status received no action 04-04-23
!status received 04-04-20
!subject Database I/O
!summary
!appendix

From: Nick Roberts
Sent: Tuesday, April 20, 2004  11:50 AM

Could I ask, please, if anyone has made a proposal that would provide some
form of database I/O (for the new revision of the language)?

I am thinking of a very minimal package, that would provide:

* opening and closing a connection by name (with implementation-specific
syntax and semantics) [a connection is to a database roughly what a file
object is to an external file];

* obtaining a list of schemata [a schema is essentially a namespace within a
database];

* opening and closing a cursor (for a named table or view (within a named
schema)) [a cursor is to a table/view roughly what a file object is to an
external file];

* obtaining information for an open cursor (e.g. field names and types);

* reading data from a cursor, and advancing the cursor;

* moving a cursor backwards, to a numbered record, or to the BOF or EOF
positions, if supported by the mechanism connected to (for the given cursor,
table/view, flags, etc.);

* updating data in the cursor, if supported by the mechanism connected to
(for the given cursor, table/view, flags, etc.).

Specifically, I am not thinking about any support for SQL, or explicit
support for transactions (or other integrity control, etc.), or anything
fancy. The interface would be suitable for reading simple files (e.g. Comma
Separated Variable-length or dBASE DBF) as well as connecting to a
full-blooded DBMS system (for the purpose of simple data retrieval and
possibly update).

There are some non-obvious issues (e.g. field types), but it seems to me
that this would make a sensible addition to the existing Ada.*_IO packages
It could be in an optional annex. I guess it's getting a bit close to the
bone for new ideas now.

****************************************************************

From: Tucker Taft
Sent: Tuesday, April 20, 2004  12:34 PM

Not as far as I know.  And unfortunately it is too late now
to get into this revision cycle.  This is more likely something
for a de-facto or secondary standard at this point.

****************************************************************

From: Marius Amado Alves
Sent: Tuesday, April 20, 2004  9:59 PM

> Could I ask, please, if anyone has made a proposal that would provide some
> form of database I/O (for the new revision of the language)?

No. I though of that, but quickly abandoned the idea because even for a
*non* minimal package too many comitiments to specific ways of databaseing
would be required, as noted below.

> * opening and closing a connection by name (with implementation-specific
> syntax and semantics) [a connection is to a database roughly what a file
> object is to an external file];

Data independence issues. Some applications could require a more 'direct'
representation. You're commiting to the client/server pattern.

> * obtaining a list of schemata [a schema is essentially a namespace within
a
> database];

Data model issues. You would have to commit to a certain metamodel.

> * opening and closing a cursor (for a named table or view (within a named
> schema)) [a cursor is to a table/view roughly what a file object is to an
> external file];

Ditto, data model. You're commiting to relational (tables). There are
alternatives e.g. network, hierachical.

> * obtaining information for an open cursor (e.g. field names and types);

Ditto, and also controversial within the relational world: some (I for one)
say that the table schema should be known to the application prior to
creating a cursor.

> There are some non-obvious issues (e.g. field types)

Field types are a BIG issue.

The SQL standard already has provisions for embedding in languages including
Ada. It's called the Module language I think, aka CLI of which the ODBC is
the most famous variant.

Sure, a database package is a must for a large class of applications. But to
design one that would satisfy everyone would be an herculean task.

I've wrote and used bindings to two relational systems (MySQL and Postgres).
The interfaces were almost identical, and I believe could be made identical,
and I think Erdmann (?) actually did a unification with his GNADE and ADBC
efforts. But both him and I had commited to a certain model, namely
relational and client/server. Now I'm writing and using a system with a
network data model (Mneson) and I can offer my experience that it seems
totally ununifiable with any of the above.

So, in sum, it's either a highly model-commited minimal annex or a 200-page
one for Ada 201Z :-)

****************************************************************

From: Nick Roberts
Sent: Thursday, April 22, 2004  10:41 PM

> > Could I ask, please, if anyone has made a proposal that would provide
> > some form of database I/O (for the new revision of the language)?
>
> No. I though of that, but quickly abandoned the idea because even for a
> *non* minimal package too many comitiments to specific ways of
> databaseing would be required, as noted below.

Hmmm. I don't want to argue too much about this subject now (in this mailing
list), but I feel that, as the quagmire of incompatibilities regarding file
I/O were very successfully overcome by the existing Ada.*_IO packages, the
problems associated with a minimal database I/O capability could also be
satisfactorily resolved.

> > * opening and closing a connection by name (with implementation-
> > specific syntax and semantics) [a connection is to a database roughly
> > what a file object is to an external file];
>
> Data independence issues. Some applications could require a more
> 'direct' representation. You're commiting to the client/server pattern.

I'm thinking of a client-server /model/, but direct access can be achieved
by using (conceptually or actually) a 'server' in the same computer
(program/process) as the client. To concoct an excample, the name string to
'connect' to a local directory containing DBF files might be
"dbf://localhost/home/nick/data" and the name string to open an ODBC
connection to a remote server might be "odbc:mydata". Both (can be made to)
fit the model quite workably. (Doesn't Microsoft's ADO work a bit like
this?)

> > * obtaining a list of schemata [a schema is essentially a namespace
> > within a database];
>
> Data model issues. You would have to commit to a certain
> metamodel.

Not really. I'm not suggesting that something like the SQL Information
Schema is required, or any extensive metamodel. Here I'm merely suggesting
that a list of schema names can be obtained (as a list or iterator of
strings). This is such a simple model, anything could be made to fit it: the
directory of DBF files could have the file names (minus the .DBF extension I
guess) as its schema names; the ODBC connection could reasonably be expected
to support SQL schemata (couldn't it?).

> > * opening and closing a cursor (for a named table or view (within a
> > named schema)) [a cursor is to a table/view roughly what a file object
> > is to an external file];
>
> Ditto, data model. You're commiting to relational (tables). There are
> alternatives e.g. network, hierachical.

Yes, but a non-flat data can /always/ be made available /as/ a flat table
(or, more likely, several related flat tables). It may be difficult or
impossible (in general) to support updating the data in these cases, but it
could be read, and that is likely to be useful.

> > * obtaining information for an open cursor (e.g. field names and types);
>
> Ditto, and also controversial within the relational world: some (I for
one)
> say that the table schema should be known to the application prior to
> creating a cursor.

But then I am indeed trying to avoid any special metamodel. In a program
with embedded (or module) SQL, you would be expected to interrogate the
Information Schema to obtain this information. Since I'm suggesting the user
cannot expect to have such a schema available, I'm just saying that the
(basic) structural (and other meta) information associated with a cursor
should be made available (by a set of appropriate interrogation functions).

> > There are some non-obvious issues (e.g. field types)
>
> Field types are a BIG issue.

Yes, I agree with that. However, I was really thinking of just some really
basic types: character (fixed length and variable length?); fixed numeric;
float and double; maybe BLOB (binary string). I know there are lots and lots
of issues about this stuff, but I'm pretty sure they can be adequately dealt
with.

> The SQL standard already has provisions for embedding in languages
> including Ada. It's called the Module language I think, aka CLI of which
> the ODBC is the most famous variant.

Well, ODBC is low-level, and defined for C (which, of course, Ada can
interface to, but it's ugly). It's SQL-specific. The SQL embedded or module
extension language is heavyweight, and overkill for most requirements. It is
also, of course, SQL-specific.

> Sure, a database package is a must for a large class of applications.

Yes, indeed it is!

> But to design one that would satisfy everyone would be an herculean
> task.

Indeed, but I didn't say I was trying to design one that would satisfy
everyone, and I'm not. I'm merely suggesting an interface that I believe
would be useful to an awful lot of Ada programs, and would provide a
lowest-common-denominator standard interface.

****************************************************************

From: Marius Amado Alves
Sent: Thursday, April 22, 2004  2:58 PM

> > Ditto, data model. You're commiting to relational (tables). There are
> > alternatives e.g. network, hierachical. (Marius)
>
> Yes, but a non-flat data can /always/ be made available /as/ a flat table
> (or, more likely, several related flat tables). It may be difficult or
> impossible (in general) to support updating the data in these cases, but
it
> could be read, and that is likely to be useful. (Nick)

You're nevertheless commiting to relational for the basis. You could go the
other way around: have a network basis, and provide a relational layer on
top of that.

But this is the only technical point we might be in disagreement. I'm
equally fond of the idea of having a standard database library. Some loose
factoids and ideas:

There are already a dozen bindings, and even a 100% Ada system if you count
Mneson.

Ada.Persistent_Containers would be an excelent basis for a standard 100% Ada
database.

I feel we're lacking a colaborative structure similar to this list and the
ARG but for separate standards.

****************************************************************

From: Robert C. Leif
Sent: Saturday, April 24, 2004  12:20 AM

A long time ago, Bill Whitaker gave a paper, I believe at a SIGAda meeting
in Fort Lauderdale, on an Ada version of SQL. There also was a different
project that created an Ada binding to SQL, which involved use of both
languages.

Please see, XQuery 1.0 and XPath 2.0 Formal Semantics
W3C Working Draft 20 February 2004 http://www.w3.org/TR/xquery-semantics/
I suspect that XQuery will become ubiquitous and that Ada could interface to
the databases and documents through XQuery. Since there is a XML schema in
the XQuery document, Ada data-types that are semantically identical to the
XQuery ones should be possible.

****************************************************************

From: Marius Amado Alves
Sent: Saturday, April 24, 2004  7:11 PM

[XQuery et al. by Robert Leif]

This just made me realise how XML can be a step forward in the adoption of
the network data model (but see Aside 1). So that's additional ammunition to
consider the network model as a basis. However XML seems powerfull enough a
movement to create their own Ada standards, independently from any other
database-oriented effort.

Aside 1. Unfortunately in my opinion XML and it's zillion standards can be
also two steps backward in data manipulation, technically. And, even keeping
with XML, NG RELAX seems a valuable alternative to XQuery et al.

Aside 2. I should perhaps clarify the my definition of "network model" is
not in line with CODASYL, perhaps the only widely known one. My definition
is more pure. Untyped graphs as a basis, plus conventions to represent
complex structures (including typed graphs) in it. In one word, Mneson.
Incidently, I've just finished the convention for XML objects, and a tool to
convert a valid XML object to Mntext. I'll update the Mneson site soon with
this stuff.

****************************************************************

From: Robert C. Leif
Sent: Saturday, April 24, 2004  11:43 AM

"NG RELAX seems a valuable alternative to XQuery et al." No!
NG RELAX is an alternative schema model, whose use should be actively
discouraged. I believe that we should stay with standard XML schema. This is
one case where the World Wide Web Consortium can learn from Ada about
creation of standards in a coordinated manor. NG RELAX seems to be favored
by Sun and IBM people. In this case Microsoft is totally correct in
specifying XML schema. Unfortunately, Microsoft has not implemented Office
using the XML FO and SVG standards. If the European Economic Union were
smart, it would fund a pan European development of a European alternative to
Office based on XML standards. Presently and in the past, Microsoft has had
the extreme good fortune of having technologically incompetent competitors.

If there is to be any further discussion on this subject, it should probably
be moved to comp.lang.ada.

****************************************************************


Questions? Ask the ACAA Technical Agent