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.
