On Friday, 4 March 2016 at 16:41:35 UTC, Chris Wright wrote:
> With embedded databases, there's a lot of variety out there, probably a decent selection of tradeoffs, so I'm not sure any one would be appropriate to phobos.

The one written from scratch specially for D (I'm talking in general, nothing particular in mind).
This is my idea of the optimal solution. And I can be wrong of course.

And there is a need for a module with interface to other databases, something like Erik's project.

Piotrek

On Friday, 4 March 2016 at 18:42:45 UTC, Erik Smith wrote:
>     auto db = createDatabase("file:///testdb");
>     auto rowSet = db.connection().statement("select name,score from score").execute;
>     foreach (r; rowSet) writeln(r[0].as!string,",",r[1].as!int);

You'll want to have some types in there. As in

struct S
{
  string name;
  int age;
}

auto rowSet = db.connection().statement("select name,score from score").executeAs!S;
foreach (r; rowSet) writeln(r.name,",",r.age);

On Friday, 4 March 2016 at 22:44:24 UTC, Sebastiaan Koppe wrote:
> On Friday, 4 March 2016 at 18:42:45 UTC, Erik Smith wrote:
>>     auto db = createDatabase("file:///testdb");
>>     auto rowSet = db.connection().statement("select name,score from score").execute;
>>     foreach (r; rowSet) writeln(r[0].as!string,",",r[1].as!int);
>
> You'll want to have some types in there. As in
>
> struct S
> {
>   string name;
>   int age;
> }
>
> auto rowSet = db.connection().statement("select name,score from score").executeAs!S;
> foreach (r; rowSet) writeln(r.name,",",r.age);


I think some basic object serialization capabilities would be great although I'm not sure how the bare names can be accessed like that through the rowSet  How would that work?  I can see this:

S s;
auto rowSet = db.connection().statement("select name,score from score").into(s);
writeln(s.name,",",s.age);


Two other options (not really serialization):

// 1
string name;
int age;
auto rowSet = db.connection().execute("select name,age from score").into(s.name,age);
foreach (r; rowSet) writeln(name,",",age);

// 2
foreach (r; rowSet) writeln(r["name"],",",r["age"]);

On Friday, 4 March 2016 at 23:55:55 UTC, Erik Smith wrote:
> I think some basic object serialization capabilities would be great although I'm not sure how the bare names can be accessed like that through the rowSet How would that work?

I did a project a while back using mysql-native (see code.dlang.org) and it has a `toStruct` function on its Row type. Maybe have a look there.

To access the bare named RowSet would have to be templated on the struct.

Follows code from said project:

template executeAs(Type)
{
	struct TypedSQLSequence
	{
		ResultSequence rs;
		alias rs this;
		@property Type front()
		{
			Row r = rs.front;
                        Type temp;
			r.toStruct!Type(temp);
			return temp;
		}
	}
	auto executeAs(ref mysql.connection.ResultSequence rs)
	{
		return TypedSQLSequence(rs);
	}
}

On Tuesday, 1 March 2016 at 21:00:30 UTC, Erik Smith wrote:
> I'm back to actively working on a std.database specification & implementation.  It's still unstable, minimally tested, and there is plenty of work to do, but I wanted to share an update on my progress.
>
> [...]

A little late to the party, nevertheless: Thanks for doing this, it will be super-helpful!

My only feature request will be: please make it work with minimal effort with Vibe.D! :)

~ sd

On 2016-03-05 11:23, Saurabh Das wrote:

> A little late to the party, nevertheless: Thanks for doing this, it will
> be super-helpful!
>
> My only feature request will be: please make it work with minimal effort
> with Vibe.D! :)

Yeah, that's really important. Unfortunately it looks like a synchronous interface is prioritized :(.

-- 
/Jacob Carlborg

On Saturday, 5 March 2016 at 13:13:09 UTC, Jacob Carlborg wrote:
> On 2016-03-05 11:23, Saurabh Das wrote:
>
>> A little late to the party, nevertheless: Thanks for doing this, it will
>> be super-helpful!
>>
>> My only feature request will be: please make it work with minimal effort
>> with Vibe.D! :)
>
> Yeah, that's really important. Unfortunately it looks like a synchronous interface is prioritized :(.


I'm definitely going to start working in async capability (or more accurately, non-blocking) into the interface.   Both models are essential and there are strong use cases for both, but I know there is a lot of interest in NBIO for vibe.d compatibility.  This is challenging and, as many are aware, the C clients for SQL databases have traditionally been synchronous only.  One suggested approach is to fork the driver source and change the I/O calls to be non-blocking. Another is to implement a non-blocking driver directly against the wire protocol (a "native" driver).  These are limited options, but to the extent this approach is viable in some cases (mysql-native for example), they could be adapted to a standard interface.  The good news is that some databases do have (or are working on) non-blocking support in their C clients. The webscalesql mysql fork, for example, has a non-blocking client that is in production and their client works with regular mysql databases.  That fork should eventually be merged back into mysql (or may have been already).  Postgres also provides non-blocking support.  These are two cases that I'm targeting for initial reference implementations.

On 2016-03-05 19:00, Erik Smith wrote:

> I'm definitely going to start working in async capability (or more
> accurately, non-blocking) into the interface.   Both models are
> essential and there are strong use cases for both, but I know there is a
> lot of interest in NBIO for vibe.d compatibility. This is challenging
> and, as many are aware, the C clients for SQL databases have
> traditionally been synchronous only.  One suggested approach is to fork
> the driver source and change the I/O calls to be non-blocking. Another
> is to implement a non-blocking driver directly against the wire protocol
> (a "native" driver).  These are limited options, but to the extent this
> approach is viable in some cases (mysql-native for example), they could
> be adapted to a standard interface.  The good news is that some
> databases do have (or are working on) non-blocking support in their C
> clients. The webscalesql mysql fork, for example, has a non-blocking
> client that is in production and their client works with regular mysql
> databases.  That fork should eventually be merged back into mysql (or
> may have been already).  Postgres also provides non-blocking support.
> These are two cases that I'm targeting for initial reference
> implementations.

Just for the record, there's already a native Postgres client that is non-blocking and vibe.d compatible. https://github.com/pszturmaj/ddb

-- 
/Jacob Carlborg

On Saturday, 5 March 2016 at 18:00:56 UTC, Erik Smith wrote:
> I'm definitely going to start working in async capability (or more accurately, non-blocking) into the interface.

Huh? Non-blocking operation is not reflected in interface. Only asynchronous requires special interface. Vibe interfaces are synchronous.

> Postgres also provides non-blocking support.  These are two cases that I'm targeting for initial reference implementations.

I've looked into OCI headers, they say something about asynchronous operations, do you know something about that?

On Sunday, 6 March 2016 at 08:53:05 UTC, Kagamin wrote:
> On Saturday, 5 March 2016 at 18:00:56 UTC, Erik Smith wrote:
>> I'm definitely going to start working in async capability (or more accurately, non-blocking) into the interface.
>
> Huh? Non-blocking operation is not reflected in interface. Only asynchronous requires special interface. Vibe interfaces are synchronous.

I think a basic non-blocking interface should be similar to the synchronous one, but also exposes a file/socket descriptor to pass to the event system and also provide status method for whether the R/W operation is waiting.

> I've looked into OCI headers, they say something about asynchronous operations, do you know something about that?

I need to look into this more, but the OCI non-blocking model is problematic (a missing file descriptor maybe).  It can probably be made to work since Node now has a driver directly from Oracle, but I'm not sure if it has the same scaling profile as other non-blocking clients.