On 2011-10-08 19:00, Andrei Alexandrescu wrote:
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
I would say that we declare a high level interface for database drivers.
std.database can use this interface to connect to all databases there
are drivers for.
We then provide driver implementations for this interface for the
databases we choose to support. It should also be possible for a user to
create his/her own driver implementation for a database we haven't yet
implemented or choose not to implement.
Driver implementations could be:
* MySQL/MariaDB
* PostgreSQL
* SQLite
* ODBC
* Oracle
* SQL Server
The smart thing would probably be to implement ODBC as the first
database driver since it would allow most of the common databases to be
used.
But I don't want ODBC to be the only driver. I have some bad experience
with ODBC from work. It can't handle multiple result sets and it's not
very good at handle invalid Unicode characters. This might not be true
for ODBC in general but it's a problem we have with the implementation
we currently use. Also, ODBC adds an extra layer between the application
and the database.
--
/Jacob Carlborg
