std.database

[Kagamin via Digitalmars-d]

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?
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.

> Another issue is that this might conflict with the notion of a 
> container and the use of opSlice.  Great feedback though and 
> I'm tracking it.

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.