[std.database]

[Jonathan M Davis]

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