List:MySQL++« Previous MessageNext Message »
From:Drew M. Date:July 13 2007 4:32am
Subject:Re: Connection::connect() interface is changing
View as plain text  
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.

That's just how I see it.

Thanks


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:
> http://lists.mysql.com/plusplus?unsub=1
>
>

Thread
Connection::connect() interface is changingWarren Young13 Jul
  • Re: Connection::connect() interface is changingDrew M.13 Jul
    • Re: Connection::connect() interface is changingWarren Young13 Jul
  • RE: Connection::connect() interface is changingYuantu.Huang13 Jul
    • Re: Connection::connect() interface is changingWarren Young13 Jul
      • RE: Connection::connect() interface is changingJoel Fielder13 Jul
        • RE: Connection::connect() interface is changingWilliam F. Dowling13 Jul
        • Re: Connection::connect() interface is changingWarren Young14 Jul
          • Re: Connection::connect() interface is changingWarren Young14 Jul
            • Re: Connection::connect() interface is changingAlex Burton15 Jul
              • Re: Connection::connect() interface is changingPeter Garner15 Jul
              • Re: Connection::connect() interface is changingWarren Young16 Jul
          • RE: Connection::connect() interface is changingJoel Fielder16 Jul
            • Re: Connection::connect() interface is changingWarren Young16 Jul
              • Re: Connection::connect() interface is changingAxel Howind16 Jul
                • Re: Connection::connect() interface is changingWarren Young16 Jul
  • Re: Connection::connect() interface is changingAxel Howind13 Jul
    • Re: Connection::connect() interface is changingWarren Young14 Jul
      • Re: Connection::connect() interface is changingAxel Howind16 Jul
  • Re: Connection::connect() interface is changingAlex Burton13 Jul
    • Re: Connection::connect() interface is changingWarren Young14 Jul
  • RE: Connection::connect() interface is changingJim Wallace13 Jul
    • Re: Connection::connect() interface is changingWarren Young14 Jul