[std.database]

[Andrei Alexandrescu]

On 10/8/11 11:49 AM, Steve Teale wrote:
> Andrei,
>
> I had a go at odbcd at about the time I first started on mysqld. I must dig it out and
> get it up to the same state so that I understand ODBC again
>
> But basically from what you're saying, all we need is the ODBC header files
> translated into D.

There's also the matter of dynamically linking with drivers I think.

> There appear to be driver managers and plenty of ODBC drivers
> for Linux.

I'm not seeing all that bonanza. First hit for ==ODBC linux== yields 
http://www.unixodbc.org/ and last update is from April 2010. Not sure 
how good it is or anything.

> But that does not get us to where I was thinking of. ODBC is not much easier to
> use than the native C apis for the databases. I had thought that ODBC was just one
> of the C database apis that we would have to cover.

1. If we build a D wrapper for ODBC, then we allow people to write code 
for any database that has an ODBC driver. This, assuming we commit to 
ODBC as D's standard database interface, would complete the project.

2. If we want to go the route of "one std.database API with drivers for 
each DBMS" and consider ODBC one of several DBMSs, then we need to 
define our own driver architecture, write a few drivers ourselves 
(including probably ODBC), and hope that people will add more drivers. 
That's a larger project but it unties us from ODBC.

3. If we want to go the route of "similar but not identical specialized 
APIs per database system" and consider ODBC again only one of the 
database systems, then we need to define one specialized API per DBMS 
and force users to essentially choose upfront what DBMS they'll use, and 
code for it. It's an even larger project and I don't see obvious 
advantages for it than less of a need for upfront design.


Andrei