RFC: mysql-native - Supporting both Vibe.d and Phobos sockets

Nick Sabalausky SeeWebsiteToContactMe at semitwist.com
Sun May 12 14:16:27 PDT 2013


There is need for mysql-native
<https://github.com/rejectedsoftware/mysql-native> to support both
Vibe.d's sockets and Phobos sockets.

First, a little background (feel free to skip ahead if you wish):
------------------------------------
Steve Teale's original version of mysql-native only supported Phobos's
sockets (there was no Vibe.d at the time). But all activity and
maintenance since then has been on a fork that *replaces* use of
Phobos's sockets with Vibe.d's sockets. Vibe.d uses its own socket
implementation instead of Phobos's because (AIUI) Phobos sockets don't
support the particular Async I/O model that's a cornerstone of Vibe.d.

There are people, including myself, who have need to use mysql-native
together with Vibe.d. But naturally, there's also very valid reasons
why mysql-native should also be usable with nothing more than Phobos,
in projects that choose not to rely on Vibe.d.
------------ (End of background) ------------

So, there's a need for mysql-native to support *both* Vibe.d and
Phobos-only, and I've already created a branch which does exactly that:

https://github.com/Abscissa/mysql-native/blob/optional-phobos-sockets/source/mysql/connection.d

You can use that with either type of socket, even switch between them
at runtime (although not within the same connection, obviously). And
you can also use an optional "-verson=" to completely eliminate any
compile-time dependency on Vibe.d (which naturally disables the ability
to use Vibe.d sockets, of course).

I've tested it on both types of sockets with mysql-native's included
test app ('source/app.d'), and it all works for me.

I *could* push that to the main mysql-native master repo right now
<https://github.com/rejectedsoftware/mysql-native>. But I'm hesitant
for one reason:

Since Phobos's and Vibe.d's sockets have incompatible APIs, my design
converts most of the types in mysql-native into templates. For example,
'Connection' becomes either 'Connection!mySQLSocketVibeD' or
'Connection!mySQLSocketPhobos'. The type 'Command' becomes either
'Command!mySQLSocketVibeD' or 'Connection!mySQLSocketPhobos'. And the
same goes for most other types, such as Row, ResultSet, etc.

That is the only breaking change, but depending how your code uses
mysql-native, it can be a very significant breaking change.

So before merging that, I wanted to get input from anyone else who has
used or contributed to either mysql-native or HibernateD
<http://sourceforge.net/p/hibernated/> which currently uses a
Phobos-only fork of  mysql-native for its MySQL capability (which is
actually my main original motivating factor for making these changes).

Couple alternatives I've considered:

- I considered templating the types on an actual socket type instead of
on "enum MySQLSocketType { phobos, vibed }", but I can't imagine a
need for any other socket type being likely to arise. And even if it
did, mysql-native would likely still need special-handling for it
anyway.

- The *ideal* solution would be for Phobos and Vibe.d to agree on a
common interface, defined in Phobos, and inherit their socket classes
from that interface. The reasons I didn't go this route are because
1) I don't know enough about the background/internals/motiovations of
either of the socket types to be the right person to spearhead this.
and 2) Such a change in Phobos would likely require a lot of time and
effort whereas my primary interest is to take mysql-native and just
*make it work* on both Phobos and Vibe.d.

If the appropriate people on both the Phobos and Vibe.d sides wanted to
spearhead an effort to make the respective sockets compatible, and
fast-track it all, then I'd be happy to make mysql-native just use
that. But I realize priorities might be elsewhere right now, and that's
perfectly fine. I figure we can just "make it work" with both types of
sockets right now (as I've already done, albeit in an unofficial
branch), and if/when a merged socket design emerges, then mysql-native
can just keep one option and deprecate the other.

Thoughts? Opinions? Etc?




More information about the Digitalmars-d mailing list