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
