mysql-native: newbie questions

[Steve Teale]

On Monday, 17 February 2014 at 22:54:58 UTC, salvari wrote:
> Hi all!
>
> After 14 years using Perl for programming at job I'm now 
> learning D. (And enjoying it)
>
> We've been using Perl (at job) for years for loading input data 
> (UTF files) into a database and using these data for different 
> purposes.
>
> The volume of input data files has been constantly increasing 
> along the years and, eventually, we need a faster solution, 
> that's the reason to switch back to compiled languages, and D 
> seemed interesting enough to give it a try. :-)
>
> As a newbie I've a few questions. I'm already using D and it's 
> working fine, although I'm writing baby-D the performance 
> improvement is impressive, I'm now trying to use mysql native 
> access. It seems there are two possibilities:
>
> - https://github.com/simendsjo/mysqln
> - https://github.com/rejectedsoftware/mysql-native

Quite by accident/coincidence, I recently returned to my mysqln 
effort to see if it would still build with the latest dmd.

I had also reinstalled MySQL recently so it was a different 
version, and that resulted in a few tweaks to the unit tests. 
However, other than that, I had no great problem.

I then set about trying to minimize memory allocations, and 
hopefully get the thing to be a bit more speedy. I think I have 
made some improvements there.

Now I realize that the code is pretty impenetrable. It's dealing 
with a protocol that is really very basic, badly documented, and 
consists of streams of ubytes minimized as much as possible, 
probably by disparate authors. You don't know what the next byte 
might represent until you've looked at the current one in 
context, so that makes it as bad a candidate for an input range 
as UTF8, or worse.

However, on a return visit, I'm not inclined to change my mind 
about the higher level interactions. I think the ability to read 
a specific table row into a tuple of D types, or to populate a D 
struct is quite cool. Also result sets with multiple rows can 
constitute an input range, so the std.algorithm stuff should be 
fine for doing finer graded selection than that provided by the 
SQL query.

If you want to do database stuff that avoids knowledge of how to 
use SQL, then I'd say it could be wrapped to provide that sort of 
thing - but then I always hated Visual Basic.

If you give me a couple of weeks or less, I'll convert it into a 
tidy module that will build with dub, and then I will invite the 
D aficionados to tell me how I can improve the efficiency of the 
protocol handling, and the template stuff that I used. From 
previous experience, I'm fairly confident that I won't get any 
takers, so I'll just keep up with the newsgroup and do the best I 
can to keep up with idiomatic D usage, as long as it's not just 
to show how cleverly things can be done.

I still quite like it, and if I had to seriously write something 
in D that needed MySQL, I would use it in preference to my 
earlier attempt at a wrapper around the C library.

But thanks for the interest
Steve.