List:MySQL++« Previous MessageNext Message »
From:Michael Hanselmann Date:April 2 2007 9:03pm
Subject:Re: Conceptual issue in mysql++ 2.2.x (use(), store(), execute())
View as plain text  
Hello Warren

On Sun, Apr 01, 2007 at 05:15:48PM -0600, Warren Young wrote:
> >Yes, it works. However, I use a somewhat different structure as you
> >see below.

> I don't see any easy way to work around this short of rolling back the
> null byte fixes in 2.2.0, which are far more important.

You refer to the "several Query objects from one connection" issue?
After looking into the code I realized that the C MySQL library supports
only one query instance at a time, anyway. Shouldn't query() on a
Connection object return the same Query instance on each call in that
case?

I agree with you that rolling back these fixes is not an option. I'll
change my code to use a single Query object only (the example below
isn't fixed yet).

> Frankly, your use of the library in this way is arguably abusive.
> Query::def is meant to contain defaults that rarely change over
> multiple queries, as you see in resetdb.

It is changing and I was only providing a stripped down example to point
out the other issue. The real code uses changing variables for every
parameter.

As an example from real code, there's a function below using only one
parameter in the template. Other functions use up to 8 different
parameters.

This code is part of a cron daemon using a database as its backend.
Since users might want to integrate it into some environment, the query
can't be fixed and needs to be customizable.

The configuration option "global.mysql.query.jobs-by-user" is set to
"SELECT jobid, owner, command, minute, hour, day_of_month, month,
day_of_week, mailto FROM job WHERE owner = %0q:owner ORDER BY jobid".

void MySqlDb::load(DatabaseResult& handler, const Database::ByOwner& filter) {
    Context c("While getting jobs by user from MySQL database");

    try {
        check_connection();

        mysqlpp::Query query = _conn.query();
        query <<
config().lookup<std::string>("global.mysql.query.jobs-by-user");
        query.parse();

        query.def["owner"] = filter.owner();

        mysqlpp::ResUse res(query.use());
        parse_query_result(handler, res);

    } catch (const mysqlpp::Exception& e) {
        throw MySqlDbError(e);
    }
}

> I recommend that you just change your code to use the single-parameter
> form of Query::use() instead of the void version, rather than use
> named template query parameters. 

Sure that'll work, but it won't solve the underlying problem with a
function behaving differently when a template contains exactly one
parameter and no parameter is passed to use()/execute()/store().

You can see the issue by looking at the produced SQL queries. The first
and only parameter is replaced by the query itself.

> The only way you can get me to relent would be to provide a patch that
> supported your use while not breaking anything else, and I might
> reject it for complexity reasons anyway.

The patch I provided in the first post of this thread "fixes" it by not
allowing a single parameter to be passed as an argument. This is the way
2.1.x did it. Yes, it might break applications already relying on that
feature. Then again, the current behaviour of 2.2.x is anything but
logical from my point of view.

> Ultimately, the problem is that we can't break the ABI right now.

The ABI isn't broken by the patch already provided, but the function's
behaviour changes.

So, one left option is to leave it as it is, another one to disallow a
single parameter being passed directly to use()/execute()/store(). What
do you think?

> I don't think it's worth trying to fix.  Just say "0" instead.  (i.e.
> pass an explicit string instead of an integer literal.)

It's not a problem I'm hitting in real code, I was just playing around
while creating the demo.

Greets,
Michael

-- 
Gentoo Linux developer, http://hansmi.ch/, http://forkbomb.ch/

Attachment: [application/pgp-signature]
Thread
Conceptual issue in mysql++ 2.2.x (use(), store(), execute())Michael Hanselmann25 Mar
  • Re: Conceptual issue in mysql++ 2.2.x (use(), store(), execute())Warren Young26 Mar
    • Re: Conceptual issue in mysql++ 2.2.x (use(), store(), execute())Michael Hanselmann26 Mar
      • Re: Conceptual issue in mysql++ 2.2.x (use(), store(), execute())Warren Young28 Mar
        • Re: Conceptual issue in mysql++ 2.2.x (use(), store(), execute())Warren Young28 Mar
        • Re: Conceptual issue in mysql++ 2.2.x (use(), store(), execute())Michael Hanselmann31 Mar
          • Re: Conceptual issue in mysql++ 2.2.x (use(), store(), execute())Warren Young2 Apr
            • Re: Conceptual issue in mysql++ 2.2.x (use(), store(), execute())Michael Hanselmann2 Apr
              • Re: Conceptual issue in mysql++ 2.2.x (use(), store(), execute())Warren Young3 Apr
                • Re: Conceptual issue in mysql++ 2.2.x (use(), store(), execute())Michael Hanselmann4 Apr
Re: Conceptual issue in mysql++ 2.2.x (use(), store(), execute())Warren Young29 Mar