I've put some still very rough generated documentation on my web page

http://britseyeview.com/software/mysqld.html

There is probably some MySQL specific stuff still in there, but I think this is close to being an interface that could be implemented for other database C api's, and for ODBC.

I'd appreciate some quick comments to find out if I am way off the mark, or if it is worth pursuing.

Thanks Steve

On Sun, 02 Oct 2011 19:52:50 +0300, Steve Teale <steve.teale@britseyeview.com> wrote:

> I've put some still very rough generated documentation on my web page
>
> http://britseyeview.com/software/mysqld.html
>
> There is probably some MySQL specific stuff still in there, but I think this
> is close to being an interface that could be implemented for other database C
> api's, and for ODBC.
>
> I'd appreciate some quick comments to find out if I am way off the mark, or if
> it is worth pursuing.

1) There seems to be a lot of MySQL-specific stuff in Connection. I guess that when/if the time comes, it will be separated into an abstract class and a MySQL specialization.
2) Setting parameters seems kinda clumsy. It should be doable with one function call with variadic template parameters.
3) In my opinion, querying the database shouldn't involve heap allocations.

I have written an SQLite wrapper (around etc.c.sqlite) for basic functionality:
https://github.com/CyberShadow/ae/blob/master/sys/sqlite3.d

Perhaps you'll find it useful for some insight towards a common interface.

-- 
Best regards,
 Vladimir                            mailto:vladimir@thecybershadow.net

On Sun, 02 Oct 2011 23:29:39 +0300, Vladimir Panteleev <vladimir@thecybershadow.net> wrote:

> 3) In my opinion, querying the database shouldn't involve heap allocations.

Erm... except for numeric values, this is almost impossible, of course - I meant to keep allocations to a minimum. For example, unless Reader preallocates - you can only read one result at a time from a Connection, so why separate the two?

-- 
Best regards,
 Vladimir                            mailto:vladimir@thecybershadow.net

Vladimir,

SQLite must have a very clean interface compared to MySQL. Your code is very terse and tidy.

You are right about the Connection stuff, and I agree with your approach.

I take your point about the parameters. I have the code to create and bind them, but that needs to be hidden away.

I don't have a strong opinion on heap allocations.

Thanks Steve

Don't forget that quite a few MySQL data structure members are C long types which are 64 bit on x86_64.

So if you want code to work on x86_64 as well as x86 it needs a type alias.

For example in st_net these members:

struct st_net
{
    Vio *vio;
    ubyte *buff;
    ubyte *buff_end;
    ubyte *write_pos;
    ubyte *read_pos;
    SOCKET fd;
    uint remain_in_buf;   <<<
    uint length;          <<<
    uint buf_length;      <<<
    uint where_b;         <<<
    uint max_packet;      <<<
    uint max_packet_size; <<<


are 32 bit on x86 and 64 bit on x86_64

Many other MySQL structures and quite a few function arguments have the same issue.

Of course, not many people seem to be using the compiler for 64 bit code at the moment.

On Sunday, October 09, 2011 19:37:31 GrahamC wrote:
> Don't forget that quite a few MySQL data structure members are C long types which are 64 bit on x86_64.
> 
> So if you want code to work on x86_64 as well as x86 it needs a type alias.
> 
> For example in st_net these members:
> 
> struct st_net
> {
>     Vio *vio;
>     ubyte *buff;
>     ubyte *buff_end;
>     ubyte *write_pos;
>     ubyte *read_pos;
>     SOCKET fd;
>     uint remain_in_buf;   <<<
>     uint length;          <<<
>     uint buf_length;      <<<
>     uint where_b;         <<<
>     uint max_packet;      <<<
>     uint max_packet_size; <<<
> 
> 
> are 32 bit on x86 and 64 bit on x86_64
> 
> Many other MySQL structures and quite a few function arguments have the same issue.
> 
> Of course, not many people seem to be using the compiler for 64 bit code at the moment.

The C types which may differ between x86 and x86_64 are defined in core.stdc.config.

- Jonathan M Davis

On Sunday, October 09, 2011 14:35:35 Jonathan M Davis wrote:
> On Sunday, October 09, 2011 19:37:31 GrahamC wrote:
> > Don't forget that quite a few MySQL data structure members are C long types which are 64 bit on x86_64.
> > 
> > So if you want code to work on x86_64 as well as x86 it needs a type alias.
> > 
> > For example in st_net these members:
> > 
> > struct st_net
> > {
> > 
> >     Vio *vio;
> >     ubyte *buff;
> >     ubyte *buff_end;
> >     ubyte *write_pos;
> >     ubyte *read_pos;
> >     SOCKET fd;
> >     uint remain_in_buf;   <<<
> >     uint length;          <<<
> >     uint buf_length;      <<<
> >     uint where_b;         <<<
> >     uint max_packet;      <<<
> >     uint max_packet_size; <<<
> > 
> > are 32 bit on x86 and 64 bit on x86_64
> > 
> > Many other MySQL structures and quite a few function arguments have the same issue.
> > 
> > Of course, not many people seem to be using the compiler for 64 bit code at the moment.
> 
> The C types which may differ between x86 and x86_64 are defined in core.stdc.config.

Though it currently only does so for the integral types.

- Jonathan M Davis

On Oct 9, 2011, at 12:37 PM, GrahamC wrote:

> Don't forget that quite a few MySQL data structure members are C long types which are 64 bit on x86_64.
> 
> So if you want code to work on x86_64 as well as x86 it needs a type alias.
> 
> For example in st_net these members:
> 
> struct st_net
> {
>    Vio *vio;
>    ubyte *buff;
>    ubyte *buff_end;
>    ubyte *write_pos;
>    ubyte *read_pos;
>    SOCKET fd;
>    uint remain_in_buf;   <<<
>    uint length;          <<<
>    uint buf_length;      <<<
>    uint where_b;         <<<
>    uint max_packet;      <<<
>    uint max_packet_size; <<<
> 
> 
> are 32 bit on x86 and 64 bit on x86_64

So use core.stdc.config.c_long?  Or is this type not actually a C long but rather a typedef that varies in some other way?

On Oct 9, 2011, at 2:42 PM, Jonathan M Davis wrote:

> On Sunday, October 09, 2011 14:35:35 Jonathan M Davis wrote:
>> On Sunday, October 09, 2011 19:37:31 GrahamC wrote:
>> 
>> The C types which may differ between x86 and x86_64 are defined in core.stdc.config.
> 
> Though it currently only does so for the integral types.

Which other standard C types vary between x86 and x86_64?

On Sunday, October 09, 2011 16:35:20 Sean Kelly wrote:
> On Oct 9, 2011, at 2:42 PM, Jonathan M Davis wrote:
> > On Sunday, October 09, 2011 14:35:35 Jonathan M Davis wrote:
> >> On Sunday, October 09, 2011 19:37:31 GrahamC wrote:
> >> 
> >> The C types which may differ between x86 and x86_64 are defined in core.stdc.config.
> > 
> > Though it currently only does so for the integral types.
> 
> Which other standard C types vary between x86 and x86_64?

On Windows, I don't believe that there's a difference on anything. On Linux, long int, unsigned long int, and long double all differ. I thought that long long int differed too (being 128 bit on 64-bit systems), but trying it now on my 64-bit Linux box, it's 64-bit for both -m32 and -m64, so I guess that it doesn't differ. But regardless, the primary one missing from core.stdc.config is long double.

- Jonathan M Davis