I have started work on MySQL++ v3.0.
My task at the moment is cleaning up the connection establishment
interface. I have something I like, but I thought I'd run it past the
list just in case.
The first thing is that we're dropping the parameters for turning on
compression and setting the connection timeout. You can set those
through Connection::set_option() instead.
The parameters for the communication channel are a mess. In v2 there
are three of them, you can't use all of them at once, and together they
select among at least four different types of IPC. (See the
mysql_real_connect() docs if you disbelieve!) I've pushed this
complexity out of the interface and into the implementation of
Connection; there's now just one string parameter for all of this, with
a bit of clever parsing within the class to figure out what you mean.
None of that should cause problems.
I am less sanguine about the next one, however. I want to reorder the
parameters to be in order of likelihood of use. I wouldn't have any
qualms about doing this if it would cause compilation problems, but the
compiler won't see any difference: all I'm doing is swapping two const
char* parameters. I figure it'll be common for people to fail to notice
the interface difference until they try to find out why their program
stopped working when rebuilding it for v3.
The final interface looks like this:
Connection(cchar* db, cchar* passwd = 0, cchar* user = 0,
cchar* server = 0, unsigned long client_flag = 0);
db is first because 99% of uses will need to specify a database. The
only use I can think of where you don't specify a database up front is
when creating databases programmatically, and that happens only once
during setup in a typical system.
The next parameter used to be host, but I figure the default works in
the majority of cases. Far more likely is the need to give a password.
A controversial aspect of this change is that the default value for
password used to be "", and is now 0 (NULL). The C API makes no
distinction between these values, for most parameters. But for
password, the former means an empty password, and the latter means the C
API library is supposed to go and read the value from a defaults file.
I figure having a defaults file is more likely than having a blank
password in this security-conscious era.
The user parameter hasn't changed, except for "" becoming 0, which is
just for stylistic consistency.
Then there's server, which stands in for the old host, port and
socket_name arguments. I figure this is less likely to be specified
than user. I know in my programs, I almost always use different user
names in my database than my login name, since database user names are
more about data access roles than overall data ownership. And, I almost
always just take the default on server address; it's running on the same
machine as the client program in most cases.
Everything else remains the same.
I'm also changing the examples' command line interfaces to match.
Complaints, comments, kudos?
