On Friday, 4 March 2016 at 11:57:49 UTC, Kagamin wrote:
On Thursday, 3 March 2016 at 18:08:26 UTC, Erik Smith wrote:
db.execute("select from t").reader; //row range
db.execute("select from t").get!long; //scalar
db.execute("select from t"); //non-query
More good options (the 3rd one is there). Also at the value
access level there are several options to consider:
v.get!long, v.as!long, v.to!long, etc.
to!long looks ok.
On the other hand execute can simply return the reader with
extra getter for scalar
result. Just don't do stuff until it's iterated. Is it
possible?
auto rows = db.execute("select * from t");
I'm hedging a bit on this because there are other capabilities
that need to be introduced that might present a problem.
Can you elaborate?
Actually I like this and I think it can work. I'm trying to keep
a single execute function name for both row/no-row queries. I can
still return the range proxy for no-row queries that is either
empty or throws on access.
On the other hand these helper methods are built on top of
abstraction API and you have to duplicate them in all drivers.
Maybe better have them as extension methods in a single module
that will work with all drivers? They are effectively a sort of
minimal frontend already.
I'm just waiting for the code to settle a bit in a basic working
state before I refactor into a two layer design.
The result set is even iterator/stream, i.e. conceptually has
even less container properties than ranges themselves. Why
would you think of it as a container? I think it's ok as input
range. Anyway, this `execute` method is a frontend, i.e. it's
replaceable without touching the driver.
The range itself is an InputRange. The statement is acting as a
container only in that it is the source of the range and holds
the data. I agree that it is confusing to use the term container
although it seems to fit the definition of one.
