Re: Connection::connect() interface is changing

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 of.

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 api:
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.

Do you need help?

In addition to our free technical library, Pantek provides professional IT services to companies who utilize Open Source software: Learn more about Pantek's Technical Support offerings Place an order for 24/7/365 Technical Support here Learn more about Pantek, who we are, and what we do Chat with a Live Operator Related lists.mysql.com Links announce benchmarks bugs certification cluster commits dotnet gui-tools internals java maxdb myodbc mysql mysqldoc packagers perl plusplus replication win32 Request more information about Pantek

That's just how I see it.

Thanks

On 7/12/07, Warren Young <mysqlpp@etr-usa.com> 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:
> http://lists.mysql.com/plusplus?unsub=ghasatta@gmail.com
>
>
Received on Fri Jul 13 00:33:13 2007