randgen team mailing list archive

[Roel Van de Paar <roel.vandepaar@xxxxxxxxxxx>]

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 <philip@xxxxxxxxx> 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: randgen@xxxxxxxxxxxxxxxxxxx
> 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 : randgen@xxxxxxxxxxxxxxxxxxx
> Unsubscribe : https://launchpad.net/~randgen More help :
> https://help.launchpad.net/ListHelp
>
>
>
>
>
>
> _______________________________________________
> Mailing list: https://launchpad.net/~randgen
> Post to     : randgen@xxxxxxxxxxxxxxxxxxx
> Unsubscribe : https://launchpad.net/~randgen
> More help   : https://help.launchpad.net/ListHelp
>
> _______________________________________________
> Mailing list: https://launchpad.net/~randgen
> Post to     : randgen@xxxxxxxxxxxxxxxxxxx
> Unsubscribe : https://launchpad.net/~randgen
> More help   : https://help.launchpad.net/ListHelp
>



-- Roel