[std.database]

[Hans Uhlig]

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.