Hi All, Hope you're all well.
This is just a little heads up that we're considering a patch to RQG. Problem description: as you know, various statuses returned by RQG are very non-descriptive. For example, when STATUS_DATABASE_CORRUPTION is triggered, it could be due to one of the 7 mapped error codes from MySQL.pm, or it could just as well be from the error message corruption validator. Consider other often unclear statuses like STATUS_ENVIRONMENT_FAILURE, PERL_FAILURE, UNKNOWN_ERROR, INTERNAL_ERROR, etc. (check MySQL.pm for more examples.) The reason is that RQG usually maps many different MySQL errors to a single STATUS code, and when returning that STATUS code it at times fails to explain what the underlying reason is. Even knowing the error code which triggered a given STATUS in a multi-threaded run would be very beneficial (there is no clear way to see this in the logs atm, and it requires wading through the logs). But as you can see from the STATUS_DATABASE_CORRUPTION example; things are not as clear as simply checking for an error code - the STATUS can also be returned from transformers, validators, reporters. Proposal: The plan we're considering is to modify the status code return to return two or more values. All of the places that check that return code will need to be modified to handle returning an array instead of a single value. We can do this. This is invasive, but if all of the transformers / validators / etc. could return a sort of "extended status" it would end up being very flexible and potentially useful for lots of other things. Benefits: clarity when it comes to any STATUS! Risk: this may temporarily unsettle the code a bit, but we will test things well internally before roll out. Thoughts? --Roel
_______________________________________________ Mailing list: https://launchpad.net/~randgen Post to : [email protected] Unsubscribe : https://launchpad.net/~randgen More help : https://help.launchpad.net/ListHelp
