Yesterday, larsivi committed an update to DDBI. It's the first work in a month or so.

http://www.dsource.org/projects/ddbi/changeset/95

>
> Initial commit for the next phase of DDBI development (I am really sorry 
that it has taken this long).
>  * First revision of the new base interfaces (in dbi/model)
>  * Implemented interfaces (95%) for mySQL - it is heavily tested, and since 
this commit does a lot, there may 
> be some glitches
> * Support for other databases will be added (sqlite is next in line), although 
this commit clear out all of the 
> old implementations. They can still be found in the tags/branches area 
of the repository.
>  * I want feedback! In particular regarding how to fetch values not as 
strings
>  * Is this an ideal minimal API that more complex functionality can be 
built on top of?
>  * This code is only tested on 32 bit linux
>

As I don't known where else to put it, I'm posting some "feedback"* and questions** here:

Does it support stored procedures?

I've been using DDBI on MySQL for a few projects and almost exclusively working via stored procedures. The old version didn't support multiple queries so it couldn't use them at all and I had to actually dig out the MySQL C API docs and figure out how to hack in support.

*I don't have time to look at the code yet so it's not really feedback.

**it's not questions either as I only have one.

BCS wrote:

> Yesterday, larsivi committed an update to DDBI. It's the first work in a month or so.

More than a month, but yeah :) Note that this is not a release, I expect those to appear when sqlite is back in.

> http://www.dsource.org/projects/ddbi/changeset/95
> 
>>
>> Initial commit for the next phase of DDBI development (I am really sorry
> that it has taken this long).
>>  * First revision of the new base interfaces (in dbi/model)
>>  * Implemented interfaces (95%) for mySQL - it is heavily tested, and
>>  since
> this commit does a lot, there may
>> be some glitches
>> * Support for other databases will be added (sqlite is next in line),
>> although
> this commit clear out all of the
>> old implementations. They can still be found in the tags/branches area
> of the repository.
>>  * I want feedback! In particular regarding how to fetch values not as
> strings
>>  * Is this an ideal minimal API that more complex functionality can be
> built on top of?
>>  * This code is only tested on 32 bit linux
>>
> 
> As I don't known where else to put it, I'm posting some "feedback"* and questions** here:
> 
> Does it support stored procedures?

It certainly isn't a case of _not_ supporting them, but I haven't actually tried or given them any thought (unlike prepared statements which is definately supported).

> I've been using DDBI on MySQL for a few projects and almost exclusively working via stored procedures. The old version didn't support multiple queries so it couldn't use them at all and I had to actually dig out the MySQL C API docs and figure out how to hack in support.

Would you mind sending me the relevant hacks so I understand your question better? The email works.

> 
> *I don't have time to look at the code yet so it's not really feedback.
> 
> **it's not questions either as I only have one.

-- 
Lars Ivar Igesund
blog at http://larsivi.net
DSource, #d.tango & #D: larsivi
Dancing the Tango

> I want feedback! In particular regarding how to fetch values not as strings

I imagine the db engines return something like this:

struct {
  int type;
  int int_data;
  char* char_data;
  bool bool_data;
  etc etc_data;
}

So I image Row.get should look like this:

T get (T=char[])(int idx) {
  static if(is(T == char[])) {
    if(fieldtype == string) return field.char_data;
    else if(fieldtype == int) return toString(field.int_data);
    else throw new Exception("Don't know how to convert from "~field.typename~" to "~T.stringof);
  }
  else static if() etc....
}

At least this is what I do with Sciter to work seamlessly with D, and this is what I plan to do with sqlite soon, if there is no other project doing it :) In my experience this stuff works great.

Regards,
bobef

bobef wrote:

>> I want feedback! In particular regarding how to fetch values not as strings
> 
> I imagine the db engines return something like this:
> 
> struct {
>   int type;
>   int int_data;
>   char* char_data;
>   bool bool_data;
>   etc etc_data;
> }

Actually, in mysql, you get the results (in normal mode, not prepared) as strings, so that is the natural way to return them, but this means that the user would have to convert them, which they may not want to do. For prepared statements, you bind storage to the result, and so you get those data directly into your storage.

> So I image Row.get should look like this:
> 
> T get (T=char[])(int idx) {
>   static if(is(T == char[])) {
>     if(fieldtype == string) return field.char_data;
>     else if(fieldtype == int) return toString(field.int_data);
>     else throw new Exception("Don't know how to convert from
>     "~field.typename~" to "~T.stringof);
>   }
>   else static if() etc....
> }

If this is how SQLite returns the data, then this approach is feasible, but
I need to make sure that the interface used is "portable" over the various
dbms.

> At least this is what I do with Sciter to work seamlessly with D, and this is what I plan to do with sqlite soon, if there is no other project doing it :) In my experience this stuff works great.

SQLite support is the next task for me on DDBI.

-- 
Lars Ivar Igesund
blog at http://larsivi.net
DSource, #d.tango & #D: larsivi
Dancing the Tango