← Back to team overview

randgen team mailing list archive

Re: Case sensitivity in Transform validator's TRANSFORM_OUTCOME_DISTINCT check

 

On 09/22/10 13:45, Philip Stoev wrote:
Hi,

I am sorry for this oversight . I did notice that the ExecuteAsUnion was producing failures, but I though they were due to some other bug about 0 v.s. NULL that is currently being fixed .

I think the best solution is to make isDistinct() case insensitive to make its behavior identical to the database one. This will fix both the ExecuteAsUnion and the Distinct validator. there is a lc() perl function that you can use.

Sounds good. Thanks for fixing it so quickly! (I will try out the fix in more detail later).


Other databases or character sets may not match the behavior in MySQL, so if the RQG ever aquires extra "customers" for Transformer-based testing, we may need to revisit the issue.

Agreed. In that case I guess it makes sense to make it more "intelligent", e.g. distinguish between products or look for actual collations used.


thanks,

--
John

----- Original Message ----- From: "John H Embretsen" <john.embretsen@xxxxxxxxxx>
To: <randgen@xxxxxxxxxxxxxxxxxxx>
Sent: Wednesday, September 22, 2010 11:38 AM
Subject: [Randgen] Case sensitivity in Transform validator's TRANSFORM_OUTCOME_DISTINCT check


Hi,


It is probably known to those of you using the Transformer validator
that some query transforms are not comparable to the original in every
case. One such case is the ExecuteAsUnion transforms when using
TRANSFORM_OUTCOME_DISTINCT against queries using varchar columns.

With this transform, results from the original query (e.g. SELECT
`col_varchar_10_latin1`  FROM L) are compared to results of transformed
queries using UNION. For example,

            (  SELECT `col_varchar_10_latin1`  FROM L    )
  UNION ALL (  SELECT `col_varchar_10_latin1`  FROM L    )
  /* TRANSFORM_OUTCOME_SUPERSET */;

where the /* TRANFORM_OUTCOME_SUPERSET */ signals to the validator that
results are OK if results from the transformed query is a superset of
the original query. This is all well.

On the other hand, one other type of transformed UNION query is:

        (  SELECT `col_varchar_10_latin1`  FROM L    )
  UNION (  SELECT `col_varchar_10_latin1`  FROM L    )
  /* TRANSFORM_OUTCOME_DISTINCT */;

where the /* TRANFORM_OUTCOME_DISTINCT */ signals to the validator that
results are OK if results from the transformed query after removing
duplicates is equal to the results of the original query.

This works OK in most cases, but when dealing with text values in a
column with a case-insensitive collation (default in MySQL) the
validator reports false positives. This is because the validator's idea
of "DISTINCT" is not equal to the the database server's idea of
DISTINCT. The issue is visible with transforms such as "ExecuteAsUnion"
and "Distinct".
[SNIP]




References