You cannot "verify" RQG behavior with respect to ROW_COUNT() by using a different mysql client than what the RQG is using (DBD::mysql). This is becacuse DBD::mysql sets the client flag mysql_client_found_rows (CLIENT_FOUND_ROWS) by default (it has been doing so since 2003, version 2.9002). This flag tells MySQL to report "matched rows" as ROW_COUNT(), whereas the default without this flag is to report "changed rows" as ROW_COUNT().
As far as I can tell the logic in ExecuteAsUpdateDelete.pm is correct when considering the Perl driver's settings, so this is likely not a bug. However, sometimes the transformer does seem to report issues that seem related to this when running the generated test cases, so there may still be something fishy going on in this area.
You cannot "verify" RQG behavior with respect to ROW_COUNT() by using a different mysql client than what the RQG is using (DBD::mysql). This is becacuse DBD::mysql sets the client flag mysql_client_ found_rows (CLIENT_FOUND_ROWS) by default (it has been doing so since 2003, version 2.9002). This flag tells MySQL to report "matched rows" as ROW_COUNT(), whereas the default without this flag is to report "changed rows" as ROW_COUNT().
http:// dev.mysql. com/doc/ refman/ 5.6/en/ information- functions. html#function_ row-count
As far as I can tell the logic in ExecuteAsUpdate Delete. pm is correct when considering the Perl driver's settings, so this is likely not a bug. However, sometimes the transformer does seem to report issues that seem related to this when running the generated test cases, so there may still be something fishy going on in this area.