MySQL Lists are EOL. Please join:

List:Commits« Previous MessageNext Message »
From:Joerg Bruehe Date:July 31 2008 2:25pm
Subject:Re: WL#4222 Test patch review
View as plain text  
Hi !

Let me join here:

Chuck Bell wrote:
> Hema,
> Above all, you need to fix the false positive test result for falcon tests
> when no falcon engine exists. This is wrong. This applies to all storage
> engines. If they aren't there the test should not say that the test passed.

 From a build team point of view, I very strongly support that:

It is mandatory for us that exactly those tests are run which check 
components (table handlers, collations, ...) configured in the build, 
and tests for other components get skipped.

For examples of this, please see the tests written by Matthias Leich in 
the "funcs1" suite, whose result files differ by the engine tested:
(all in "mysql-test/suite/funcs_1/t/").

In these tests, you should see the mechanism used to skip (controlled by 
the presence of a feature) and to write a meaningful comment into the 
output (which is in the release build log we keep archived).

For another way of skipping, controlled by the comment string which we 
set in the release build, see the "charset_collation_*.test" files in 
the same directory.

> Chuck 
>> -----Original Message-----
>> From: Hema Sridharan [mailto:hema@stripped] 
>> Sent: Wednesday, July 23, 2008 0:35 AM
>> To: 'Chuck Bell'
>> Cc: 'Rafal Somla'; 'Lars Thalmann'; commits@stripped
>> Subject: RE: WL#4222 Test patch review
>> Hi Chuck,
>> I created this patch after taking your suggestion in IRC on 
>> 07/02. For my proposal , "replacing by default storage 
>> engines, if the engines like Falcon(or Innodb) is not 
>> compiled in the BUILD" you gave your approval and that's why 
>> I proceeded. 

I don't know the communication between you, so this is a general remark:

IMNSHO, the silent replacement of one storage engine by another is a 
perfect way to make tests fail.
In production environments, it might make the system behave in an 
un-expected and un-intended way, which may cause wrong data and so be a 
bad failure for the user/customer.
For a recent example, see my report of bug#37976.

I would rather have the system throw an error if a request (say, to use 
a certain table handler) cannot be fulfilled than have it continue with 
changed semantics (say, without transactions).


Joerg Bruehe,  MySQL Build Team,  joerg@stripped   (+49 30) 417 01 487
Sun Microsystems GmbH,   Sonnenallee 1,   D-85551 Kirchheim-Heimstetten
Geschaeftsfuehrer: Thomas Schroeder, Wolfgang Engels, Dr. Roland Boemer
Vorsitzender des Aufsichtsrates: Martin Haering     Muenchen: HRB161028

WL#4222 Test patch reviewChuck Bell12 Jun
  • RE: WL#4222 Test patch reviewHema Sridharan13 Jun
    • RE: WL#4222 Test patch reviewChuck Bell13 Jun
      • RE: WL#4222 Test patch reviewHema Sridharan24 Jun
        • RE: WL#4222 Test patch reviewChuck Bell30 Jun
          • RE: WL#4222 Test patch reviewHema Sridharan1 Jul
            • RE: WL#4222 Test patch reviewChuck Bell1 Jul
              • RE: WL#4222 Test patch reviewHema Sridharan2 Jul
                • RE: WL#4222 Test patch reviewChuck Bell2 Jul
                  • RE: WL#4222 Test patch reviewHema Sridharan3 Jul
                    • RE: WL#4222 Test patch reviewChuck Bell21 Jul
                      • RE: WL#4222 Test patch reviewHema Sridharan23 Jul
                        • RE: WL#4222 Test patch reviewChuck Bell23 Jul
                          • Re: WL#4222 Test patch reviewJoerg Bruehe31 Jul
                            • RE: WL#4222 Test patch reviewHema Sridharan1 Aug
                              • Re: WL#4222 Test patch reviewJoerg Bruehe1 Aug
                      • RE: WL#4222 Test patch reviewHema Sridharan7 Aug
                        • RE: WL#4222 Test patch reviewChuck Bell11 Aug
                          • RE: WL#4222 Test patch reviewHema Sridharan11 Aug
RE: WL#4222 Test patch reviewChuck Bell30 Jun
  • RE: WL#4222 Test patch reviewHema Sridharan30 Jun