Version 1.1 of acs/ac-00097.txt

Unformatted version of acs/ac-00097.txt version 1.1
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.

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


Questions? Ask the ACAA Technical Agent