Warren Young schrieb:
> I am less sanguine about the next one, however. I want to reorder the
> parameters to be in order of likelihood of use.
A change that will cause a lot of headache...
We need to maintain code that runs on systems where the newest library
versions are not yet available. This means, while making the transition,
the code must compile under old and new versions of MySQL++ (using ugly
#ifdefs). I am sure a change like this will slip through when the code
compiles out of the box with the new version.
Likelohood of use is something that depends highly upon where you use
MySQL++. Here, for example we always need to specify the host, since
client and server normally do not run on the same machine.
Personally, I even think it is no good to have default parameters for
setting up connections at all: this is something where I always want the
developper to better think twice than just proceed using the default values.
Also, I would expect a program where you can't configure the database
via i.e. command line parameters, a configuration file etc to be the
exceptional case, not the standard. Breaking the interface in such a
subtle way (no compilation errors) to simplyfy the exceptional case
would IMHO not be worth the trouble generated.
> The final interface looks like this:
>
> Connection(cchar* db, cchar* passwd = 0, cchar* user = 0,
> cchar* server = 0, unsigned long client_flag = 0);
Specifying a password and no user is quite exceptional and might
introduce security issues. If one absolutely wants to use the login of
the user the program is running under (I have btw never seen databases
set up like this in practice, are there?), let him explicitly make it
clear by passing 0 as user.
There is nothing against pulling compression and timeout out here, but I
would prefer a less abrupt change like this:
mysqlpp::Connection::Connection (
const char * db,
const char * host = 0,
const char * user = 0,
const char * passwd = 0,
uint port = 0,
const char * socket_name = 0,
unsigned int client_flag = 0
)
Like this, parameters up to port stay the same and programs using only
these would stay source compatible. The reason to have socket_name
before client_flag is to make sure programs specifying compress etc do
actually break during compilation (the 6th parameter used to be bool)
and make the interface change obvious.
Axel
