Databases and the D Standard Library

[Chris Wright via Digitalmars-d]

On Tue, 03 Jan 2017 13:23:55 +0100, Jacob Carlborg wrote:

> On 2017-01-03 09:38, Chris Wright wrote:
> 
>> 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.
> 
> That's true. And that's why I said it's difficult to design an API
> without trying it in code :)

I didn't try it in code.

>> 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.
> 
> 1. I hope there won't be that many buffers in the API, at least not in
> the user facing API

The returned row data is mandatory, and its size can be much larger than 
the stack limit. (A MySQL MEDIUMBLOB field will likely break your stack 
limit.)

I suppose you could have a streaming API for row data, one that has a 
stack-allocated buffer and returns slices of that:

  string fieldName;
  ubyte[] data;
  ubyte[][string] fields;
  db.query("SELECT * FROM USERS")
    // have to revisit this if a db allows large names
    .onFieldStart((fieldName) => field = fieldName)
    .onFieldData((fragment) => data ~= fragment)
    .onFieldEnd(() { fields[field] = data; data = null; })
    .onRowEnd(() => process(fields))
    .onResultsEnd!(() => writeln("done"))
    .exec();

This looks pretty terrible, to be honest. I get this sort of thing from 
nodejs because it doesn't want to potentially block and also doesn't want 
to delay letting me process things, but the worst I get there is usually 
two callbacks.

This would also result in more GC use for the majority of people who use 
the GC.

> 2. Buffers say nothing how they're allocated. With classes on the other
> hand, you're basically forced to allocate with the GC

You haven't looked at std.experimental.allocator, have you?

http://dpldocs.info/experimental-docs/std.conv.emplace.3.html
http://dpldocs.info/experimental-docs/std.experimental.allocator.make.html
http://dpldocs.info/experimental-docs/
std.experimental.allocator.dispose.2.html