std.database

[Erik Smith via Digitalmars-d]

Hi Stefan,

It might be a challenge for CTFE compatibility in the API, but it 
would be interesting to see how much of it is workable.  There 
does need to be some optional API elements in cases where it's 
not supported by the underlying database client(array binding for 
example) and these compile time policies could also be used to 
define a restricted subset if needed for your design.

I don't have any D code in production unfortunately, but I have a 
similar design in C++ that has been in production for years.

As far as the design rationale, the primary aspect of the design 
is to ensure deterministic resource lifetimes for each of the 
resources commonly exposed by clients (connections, statements, 
rowsets, buffer allocations, etc), which is why structs are used. 
  This could be done with with simple non-copyable structs for a 
more limited design.  I went with the value type structs (using 
reference counting) which provides better composibility overall.  
This can be seen in the call chaining examples, which I think 
significantly increase ease-of-use.  It also covers use cases in 
application code where, for example, lazy results are returned 
through code layers and they need to retain their underlying 
connections.

Thanks for the questions and the interest.

erik