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
