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