[std.database]

[Steve Teale]

As in the initial discussions on database interfaces, I am still of
the view that such support should be provided at three levels. I also
suggest that we adopt a proposal that was hinted at in the initial
discussions, and think in the longer term of having components that
are devoted to SQL, and those that will apply to a broader view of
what comprises a database. In other words we should have std.sql and
std.database. (I use std purely for illustration.)

It's possibly worth mentioning that Microsoft had similar intentions
years ago when they introduced OLE DB - a generalized interface to
data sources. OLE DB is now being dumped. I should make it clear that
what I'm working on at present are modules for xxx.sql. It has been
pointed out in several postings that I don't seem to have any clear
idea of the design requirements for std.database, and I admit that
this is the case, though I don't think I'm alone in this. The initial
discussions did not reach any well defined conclusions.

If there is anyone who wants to leap into the std.database role,
please volunteer. It could take me some time to get the SQL stuff in
some sort of order. ODBC is a set of dialects, and the wire protocol
definitions are not easy to get up-to-speed on.

It seems that given licensing considerations, D support for SQL will
probably need to be distributed. Some C header translations will have
to go in Deimos - e.g. MySQL, some would probably be OK in Phobos,
e.g. SQLite, and _maybe_ ODBC, (Would you believe that some driver and
driver manager implementations have attached GPL wording to the ODBC
header files!) and PostgreSQL.

Having done quite a bit of work on implementations for MySQL (C API
and wire protocol), and SQL Server (ODBC from Linux and Windows), I'm
beginning to have some fairly clear ideas about what D components for
dealing with SQL databases, using SQL directly, could look like. More
detail on that separately.

An immediate point that arises is that because some of the D 'header
files' are derivative, and the associated D components need to link
with external libraries, we're missing a place to put such components.
They can't go in Phobos because of the licensing and linking
considerations, and they can't go in Deimos because that is for
translations of C header files only.

At the same time, It seems to me that they should follow the same
quite tight implementation pattern as those that can potentially go
in Phobos. Someone going from say the C API version of the MySQL
interface should be able to use the same, or closely similar code as
when using the wire-protocol version.

So one question is where should such implementations go?

Another questions relates to the definition of interfaces at module
level. We have interfaces that go hand-in-hand with classes built in
to the language. But if I wanted to say that two sql interface modules
had the same 'interface', how could this be formalized. Could it be
done using contracts? I'd welcome suggestions on this.

Steve