For those who aren't aware: mysql-native (aka "mysqln") is a native-D MySQL client library that has zero dependencies on the official MySQL client lib or any other [L]GPL software. It was originally created by Steve Teale, but various other people have since been maintaining it. Originally it used Phobos's sockets, but then it was switched over to Vibe.d sockets in order to support Vibe.d users.

Contrary to what I originally thought, it turned out to be possible to add optional support for Phobos sockets back in without any breaking changes at all. It's now up in the main repo's master:

https://github.com/rejectedsoftware/mysql-native

If you've already been using mysql-native with Vibe.d, then this should work out-of-the-box with no changes at all.

If you want to use Phobos sockets, you can do it two ways:

1. Pass -version=MySQLN_NoVibeD to the compiler. This will completely eliminate all dependencies on Vibe.d (and remove all Vibe.d capabilities, naturally) and automatically use Phobos sockets. Everything else will be exactly the same (But see the "caveat" below).

2. Add "MySQLSocketType.phobos" as the (optional) first argument to
Connection's constructor:

----------------
auto conn = Connection(MySQLSocketType.phobos, "localhost", "user",
"pass", etc...);
----------------

While it's probably best to stick to Vibe.d sockets in any app that uses Vibe.d, if you have any reason to choose the socket type at run-time, you can do so using this method.

Additionally, you're not limited to the stock sockets: You can also use any custom socket type derived from either std.socket.TcpSocket or vibe.core.net.TcpConnection (dependency injection, perhaps?) like this:

----------------
static auto openCustomSocket(string host, ushort port)
{
    auto s = new MyCustomTcpSocket();
    s.open(host, port);
    return s;
}
auto conn = Connection(&openCustomSocket, "localhost", "user", "pass",
etc...);
----------------

One caveat:

The EventedObject feature and the related MySQL connection pool class ("mysql.db.MysqlDB") are still Vibe.d-only, and will likely stay that way since they're entirely Vibe.d-specific features.

The EventedObject methods (ie: acquire/release/isOwner/amOwner) still exist in mysql-native's Connection class regardless of socket type (and regardless of -version=MySQLN_NoVibeD) and can always be used. But for Phobos-based sockets they're stubbed out as no-ops. This won't affect most people at all, but it does mean that the MySQL connection pool class ("mysql.db.MysqlDB") *always* uses Vibe.d sockets, and cannot even be imported at all if you use -version=MySQLN_NoVibeD

On Fri, 17 May 2013 02:08:05 -0400
Nick Sabalausky <SeeWebsiteToContactMe@semitwist.com> wrote:
> 
> If you want to use Phobos sockets, you can do it two ways:
> 
> 1. Pass -version=MySQLN_NoVibeD to the compiler. This will completely eliminate all dependencies on Vibe.d (and remove all Vibe.d capabilities, naturally) and automatically use Phobos sockets. Everything else will be exactly the same (But see the "caveat" below).
> 

Since it makes a lot more sense for the default to be *no* external dependencies, I've flipped it around:

By default, mysql-native is now Phobos-only and does *not* depend on Vibe.d (or any other third party lib).

To enable the optional Vibe.d support (which also makes Vibe.d sockets the default instead of Phobos sockets, although you can explicitly choose either at runtime), then include the following compiler flag:

  -version=Have_vibe_d

That flag above will be included automatically if you compile using DUB, and your project uses Vibe.d.

> Since it makes a lot more sense for the default to be *no*
> external dependencies, I've flipped it around:

That's great thanks for your work on this.

One question, is there any plans to add transaction support?

On Tuesday, 21 May 2013 at 09:19:04 UTC, Gary Willoughby wrote:
> One question, is there any plans to add transaction support?

Actually this is a dumb idea, i can just send the SQL myself.

On Tue, 21 May 2013 11:21:51 +0200
"Gary Willoughby" <dev@kalekold.net> wrote:

> On Tuesday, 21 May 2013 at 09:19:04 UTC, Gary Willoughby wrote:
> > One question, is there any plans to add transaction support?
> 
> Actually this is a dumb idea, i can just send the SQL myself.

D is freaking awesome for that though:

// Psuedocode
START TRANSACTION;
scope(fail) ROLLBACK;
scope(exit) COMMIT;

Nice :)

On Tuesday, 21 May 2013 at 10:12:41 UTC, Nick Sabalausky wrote:
> // Psuedocode
> START TRANSACTION;
> scope(fail) ROLLBACK;
> scope(exit) COMMIT;
>
> Nice :)

You may have meant "scope(success) COMMIT;", scope(exit) is executed on both failure and success.

On Tue, 21 May 2013 12:16:43 +0200
"Dicebot" <m.strashun@gmail.com> wrote:

> On Tuesday, 21 May 2013 at 10:12:41 UTC, Nick Sabalausky wrote:
> > // Psuedocode
> > START TRANSACTION;
> > scope(fail) ROLLBACK;
> > scope(exit) COMMIT;
> >
> > Nice :)
> 
> You may have meant "scope(success) COMMIT;", scope(exit) is executed on both failure and success.

Indeed I did. That's what I get for posting on my way to bed ;)

I've found a couple more 'bugs'. Well warnings really but should be addressed.

In connection.d:

lines 2022-2023 should be:

@property ParamDescription[] paramDescriptions() { return _paramDescriptions; }
@property FieldDescription[] fieldDescriptions() { return _colDescriptions; }

i.e. missing property attribute.

and line 2345 is unreachable, containing just:

break;


Compiled with: rdmd --force -w -property test.d