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

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

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

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.

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

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

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

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

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

real is the same size as long double, on both 32 and 64 bits linux.
--
Mike Wey