← Back to team overview

randgen team mailing list archive

Re: --sqltrace: OK to mark bad queries?



The suggested changes are now in the randgen tree on Launchpad. See
revid john.embretsen@xxxxxxxxxx-20110928192605-7ffumru4ipcja7h0.

Invalid queries are now prefixed with

# [sqltrace] ERROR <errno>:

when using --sqltrace and the MySQL executor.


On Thu, Sep 8, 2011 at 5:45 PM, Philip Stoev <philip@xxxxxxxxx> wrote:
> Although I do not use --sqltrace myself, I am fine with your suggestion.
> I think you can modify the behavior right away, there is not need to make
> the new feature optional.
> Philip Stoev
> ----- Original Message ----- From: "John H. Embretsen" <johnemb@xxxxxxxxx>
> To: <randgen@xxxxxxxxxxxxxxxxxxx>
> Sent: Thursday, September 08, 2011 6:08 PM
> Subject: [Randgen] --sqltrace: OK to mark bad queries?
>> Hi all,
>> There is an RQG option --sqltrace which makes the executors print each
>> SQL query to standard output when it gets executed (or actually, right
>> before).
>> I know some of you use this feature for various purposes. I hereby
>> suggest to make a change to the default behavior of this feature (at
>> least for the MySQL part of it), so please let me know if you think it
>> is not a good idea or would break too many applications.
>> Rationale:
>> Sometimes --sqltrace is useful for replaying RQG runs, query by query.
>> This is for example useful when server query logs are not available.
>> It is also relatively easy for novice RQG users to use. However, when
>> using this trace as basis for a regular test case (e.g. for
>> MTR/mysql-test), including the queries that result in errors is
>> generally not useful. And it is hard to filter out those queries by
>> hand afterwards.
>> So, my suggestion is to mark such queries so that they can be easily
>> filtered out when needed. To make it as simple as possible, I suggest
>> prefixing all such queries with the RQG comment symbol (#) and maybe
>> some text like "ERROR <NN>" (NN being the error code if available),
>> for example:
>> "# ERROR 1146: SELECT non-existing-column FROM t1 ;"
>> Valid queries will still be printed as:
>> "SELECT valid_column FROM t1 ;"
>> This will also mean that the query will not be printed until directly
>> after execution, as we won't know if it is valid or not before.
>> Hopefully it is not an issue (unless you have a hanging query or
>> something like that).
>> I only plan to modify the MySQL executor for now.
>> Let me know if you have opinions, otherwise I will execute on the plan
>> "soonish".
>> An alternative way would be to make the new behavior optional, but I
>> would like to avoid adding new options and alternatives if I can avoid
>> it.
>> Thanks,
>> --
>> John
>> _______________________________________________
>> Mailing list: https://launchpad.net/~randgen
>> Post to     : randgen@xxxxxxxxxxxxxxxxxxx
>> Unsubscribe : https://launchpad.net/~randgen
>> More help   : https://help.launchpad.net/ListHelp

Follow ups