On 2017-01-03 18:13, Chris Wright wrote:
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.
Look, I didn't say that using the GC should be completely forbidden. I
just said we should try to avoid it. For example, I've been using the
ddb Postgres driver [1]. It uses classes for most of its types, even if
it might not be necessary. Here's one example [2], unless there some
intention to have some form of higher level, DB independent, API on top
of this, I don't see a reason why that type needs to be a class.
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?
I know it's possible to allocate a class without the GC, hence the
"basically". I'm not sure how other write their code but at least I make
the assumption that all objects are allocated with the GC.
[1] https://github.com/pszturmaj/ddb
[2] https://github.com/pszturmaj/ddb/blob/master/source/ddb/postgres.d#L904
--
/Jacob Carlborg
