All, Thank you for the great feedback. I will check with our helpful Perl programmer and see if he can incorporate this inc. the suggestions made.
On Wed, Aug 27, 2014 at 7:10 PM, Philip Stoev <[email protected]> wrote: > In Perl you are allowed to return multiple values from a routine. Callers > who expect only a single return value will only get one of the values > returned (the leftmost?) > > So the original status codes can be retained as it is and more detailed > statuses can be gradually introduced as a second value being returned from > routines. > > Philip Stoev > > -----Original Message----- From: Bernt Marius Johnsen > Sent: Wednesday, August 27, 2014 11:55 > To: [email protected] > Subject: Re: [Randgen] Better/mode detailed STATUS reporting > > > > Hi, > > I have played with the same thought. But in my mind, I have visioned a > more complex status object. Bear in mind that the status reporting is both > on return from subroutines and return from perl scripts called from other > perl scripts so it must be very carefully designed. > > > On 08/26/2014 10:50 PM, Roel Van de Paar wrote: > > 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 > > > > > > > _______________________________________________ > Mailing list: https://launchpad.net/~randgen > Post to : [email protected] > Unsubscribe : https://launchpad.net/~randgen > More help : https://help.launchpad.net/ListHelp > > _______________________________________________ > Mailing list: https://launchpad.net/~randgen > Post to : [email protected] > Unsubscribe : https://launchpad.net/~randgen > More help : https://help.launchpad.net/ListHelp > -- Roel
_______________________________________________ Mailing list: https://launchpad.net/~randgen Post to : [email protected] Unsubscribe : https://launchpad.net/~randgen More help : https://help.launchpad.net/ListHelp
