On Friday, December 02, 2011 16:02:59 Hans Uhlig wrote: > On 10/9/2011 2:50 AM, Jacob Carlborg wrote: > > 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. > > One thing I notice is everyone seems to only be Targeting Relational > Databases. Any plans to support Flat, Object, Key Value, Hierarchical, > or Network Model systems? It would be nice to have at least > specification support for systems like membase(memcache), hbase, > vertica, csv files, and similar systems.
Well, I wouldn't expect them to use the same API, but it's stuff like that why it's been suggested suggested that we make it std.sql instead of std.database. - Jonathan M Davis
