Databases and the D Standard Library

[Adam Wilson via Digitalmars-d]

On 1/2/17 12:09 AM, Jacob Carlborg wrote:
> On 2017-01-02 02:34, Adam Wilson wrote:
>
>> That was my intention, the knee-jerk reaction that class and interfaces
>> get here sometimes strikes me as a bit histrionic sometimes. They are a
>> tool with a use case. :)
>
> I think that the design should try to avoid classes as much as possible
> for things that will be frequently created. It's always possible to wrap
> a struct in a class, the other way around is a bit more difficult. But
> when it comes to the connection object I think it's fine to use classes
> since it will most likely only be created once per thread.
>

Ok. How would you design a database API for D?

The requirements I am operating under are:

1. Individual data-store driver implementations are not included in the 
D Standard Library. Driver licensing and implementation details vary. 
For example libpq5 uses it's own mix of licenses that is not Boost 
compatible.

2. The D Standard Library provides a common API and implementation of 
shared components, but leaves the data-store specific implementation up 
to the implementer. We don't care how the implementation is constructed 
or licensed, only that the API is followed.

3. In order to support higher level abstractions like ORM's we need a 
base class model that can be extended by implementers but still consumed 
by the ORM without knowing implementation specific details.

As far as I am aware, the only way to meet those requirements is to use 
a base-class model. Is there something I am missing?

-- 
Adam Wilson
IRC: LightBender
import quiet.dlang.dev;