I'm working on a standards grade interface & implementation for database clients in D.  It defines a common interface (the implicit kind) and allows for both native and polymorphic drivers.  A key feature is a range interface to query results.

Here's the project page with the design highlights and examples of usage:

https://github.com/cruisercoder/ddb

The implementation is in the early stages and only a few things work, but I'm planning to include sqlite, mysql, Oracle, and ODBC reference implementations.

I could use some feedback on the basic approach I'm taking and to help ensure that I'm not doing something horribly wrong with my basic D skills.

erik

On 28/05/2015 2:04 p.m., Erik Smith wrote:
> I'm working on a standards grade interface & implementation for database
> clients in D.  It defines a common interface (the implicit kind) and
> allows for both native and polymorphic drivers.  A key feature is a
> range interface to query results.
>
> Here's the project page with the design highlights and examples of usage:
>
> https://github.com/cruisercoder/ddb
>
> The implementation is in the early stages and only a few things work,
> but I'm planning to include sqlite, mysql, Oracle, and ODBC reference
> implementations.
>
> I could use some feedback on the basic approach I'm taking and to help
> ensure that I'm not doing something horribly wrong with my basic D skills.
>
> erik
>

Feel free to come on https://gitter.im/DNetDev/Public to chat.
I was thinking about doing something along these lines eventually. Since Dvorm is going away.

I believe you're a aiming to low.

If you have a struct you could use traits and ctfe to generate perfect sql statements. This would make it possible to a range of "struct Customers".

That would be awesome

On Thursday, 28 May 2015 at 03:40:36 UTC, Robert burner Schadek wrote:
> I believe you're a aiming to low.
>
> If you have a struct you could use traits and ctfe to generate perfect sql statements. This would make it possible to a range of "struct Customers".
>
> That would be awesome

I agree that it would be awesome.  I see that kind of query generation framework being built separately on top of this layer.

erik

On Thursday, 28 May 2015 at 02:04:31 UTC, Erik Smith wrote:

Shouldn't the statement be reusable? I.e. bind variables and run multiple times. From the code examples creating a statement and binding variables seemed to be coupled.

Since one obvious use case would be running the behind a http server - vibe.d - using fibers and using yield would seem nice to have.

In any case it should do one thing, and do it well. All the other fancy features like orms and auto-struct bindings should be build ontop (maybe as separate libs)

> Shouldn't the statement be reusable?

Yes it should.  I added this use case:

auto stmt = con.statement("insert into table values(?,?)");
stmt.execute("a",1);
stmt.execute("b",2);
stmt.execute("c",3);

> Since one obvious use case would be running the behind a http server - vibe.d - using fibers and using yield would seem nice to have.

I think it's agnostic to fibers but I'm not sure.

> In any case it should do one thing, and do it well. All the other fancy features like orms and auto-struct bindings should be build ontop (maybe as separate libs)

Agree.

On Thursday, 28 May 2015 at 04:45:52 UTC, Erik Smith wrote:
>> Shouldn't the statement be reusable?
>
> Yes it should.  I added this use case:
>
> auto stmt = con.statement("insert into table values(?,?)");
> stmt.execute("a",1);
> stmt.execute("b",2);
> stmt.execute("c",3);
>

struct Table;

Table a, b, c;

con.insert!Table(a);
...

if you use CTFE to create the statement string there is no reason to reuse it.
it will be string literal, that's even better! Think Big. Think D

the other code is Java not D

On 28/05/2015 4:57 p.m., Robert burner Schadek wrote:
> On Thursday, 28 May 2015 at 04:45:52 UTC, Erik Smith wrote:
>>> Shouldn't the statement be reusable?
>>
>> Yes it should.  I added this use case:
>>
>> auto stmt = con.statement("insert into table values(?,?)");
>> stmt.execute("a",1);
>> stmt.execute("b",2);
>> stmt.execute("c",3);
>>
>
> struct Table;
>
> Table a, b, c;
>
> con.insert!Table(a);
> ...
>
> if you use CTFE to create the statement string there is no reason to
> reuse it.
> it will be string literal, that's even better! Think Big. Think D
>
> the other code is Java not D

Then you open up table names, property serialization ext. ext.
Please no.
That is an ORM's job. I'm saying this from experience.

On Thursday, 28 May 2015 at 05:00:30 UTC, Rikki Cattermole wrote:
> On 28/05/2015 4:57 p.m., Robert burner Schadek wrote:
>> On Thursday, 28 May 2015 at 04:45:52 UTC, Erik Smith wrote:
>>>> Shouldn't the statement be reusable?
>>>
>>> Yes it should.  I added this use case:
>>>
>>> auto stmt = con.statement("insert into table values(?,?)");
>>> stmt.execute("a",1);
>>> stmt.execute("b",2);
>>> stmt.execute("c",3);
>>>
>>
>> struct Table;
>>
>> Table a, b, c;
>>
>> con.insert!Table(a);
>> ...
>>
>> if you use CTFE to create the statement string there is no reason to
>> reuse it.
>> it will be string literal, that's even better! Think Big. Think D
>>
>> the other code is Java not D
>
> Then you open up table names, property serialization ext. ext.
> Please no.
> That is an ORM's job. I'm saying this from experience.

Similar project: DDBC https://github.com/buggins/ddbc
Inspired by Java JDBC API.
Currently supports MySQL, PostreSQL, SQLite.

> Table a, b, c;
>
> con.insert!Table(a);
> ...
>
> if you use CTFE to create the statement string there is no reason to reuse it.
> it will be string literal, that's even better! Think Big. Think D
>
> the other code is Java not D

The statement reuse with binding is primarily for performance and is important for many use cases.

I get that it looks like Java, but that's because it's wrapping around the familiar constructs of a database client API that similar across languages.   Also, I think has the potential to be much better than JDBC with the deterministic resource management, variadic functions, and higher performance.

An independent query generation / ORM layer would be a nice complement though.

erik