Warren (and list),
If it ain't broke....
I don't see a compelling need to rearrange the arguments for the connect
interface, unless there have been a lot of complaints that I am not aware
On the other hand, I think there is a high potential for confusion. It may
just be me, but the arrangement you propose doesn't really feel intuitive.
Password before username in particular is a change I will have a hard time
getting used to. When one connects to mysql via the command line client,
database is always the last argument given.
For comparison, here is how the mysql_real_connect function looks in the C
MYSQL *mysql_real_connect(MYSQL *mysql, const char *host, const char *user,
const char *passwd, const char *db, unsigned int port, const char
*unix_socket, unsigned long client_flag)
Notice that the order of args is host, user, password, db.
I think that the potential for confusion on this is enough to warrant just
leaving it alone. I foresee lots of torn-out hair from people trying to
figure out why they can connect to mysql via the C API (or command line
client) but not mysql++.
You could argue that these people should just read the documentation -- but
I say let's have a compelling reason for this change first.
That's just how I see it.
On 7/12/07, Warren Young <mysqlpp@stripped> wrote:
> 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?
> MySQL++ Mailing List
> For list archives: http://lists.mysql.com/plusplus
> To unsubscribe: