← Back to team overview

randgen team mailing list archive

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

 

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

References