Databases and the D Standard Library

[Chris Wright via Digitalmars-d]

On Tue, 03 Jan 2017 08:25:55 +0100, Jacob Carlborg wrote:

> Structs and functions, with or without templates. Could something like
> this work:
> 
> module db_interface;
> 
> version (Postgres)
>      public import pg.db_interface;
> else version (MySQL)
>      public import mysql.db_interface;

You are unable to interact with two different databases in the same 
executable using the same library. For instance, if you're using 
hibernated, either you compiled it to connect to mysql, or you compiled 
it to connect to oracle.

This means you can't, for instance, use mysql for the CI server (because 
it's open source and doesn't have licensing fees), then use oracle for 
production (because it's faster for your workflow), because then you're 
testing with a different binary. You can't have some data in postgres and 
some in SQL Server because you're in the middle of a migration.

You can still use both if you are using the database interface directly. 
But if you're connecting via a library, you're SOL.

You have to recompile everything whenever you switch databases. That's a 
barrier to proprietary libraries that interact with databases. They're 
not impossible, but they have to release separate binaries for every 
database the maintainer thinks you might want to connect to.

Every library that lets you access a database must maintain a list of db 
drivers that it supports. If you have a new or private driver you want to 
use, you need to modify any library you use that talks to a database.

In exchange, you get...slightly less GC usage. It's not *no* GC usage -- 
you'll see a bunch of buffers allocated to hold incoming and outgoing 
messages. You'll just peel back one layer of it.

You'd be much better off asking that we encourage the use of 
std.experimental.allocator in the driver interface.