Re: Comments from Monty [Fwd: re: bzr commit into MySQL/Maria:mysql-maria branch (guilhem:2741)]

[Mattias Jonsson]

Hi,

There was no change in any error message. The real change was this:

=== modified file 'sql/handler.cc'
--- a/sql/handler.cc	2009-02-10 08:37:27 +0000
+++ b/sql/handler.cc	2009-02-18 20:29:30 +0000
@@ -2932,7 +2932,7 @@ uint handler::get_dup_key(int error)
    if (error == HA_ERR_FOUND_DUPP_KEY || error == 
HA_ERR_FOREIGN_DUPLICATE_KEY ||
        error == HA_ERR_FOUND_DUPP_UNIQUE || error == 
HA_ERR_NULL_IN_SPATIAL ||
        error == HA_ERR_DROP_INDEX_FK)
-    info(HA_STATUS_ERRKEY | HA_STATUS_NO_LOCK);
+    table->file->info(HA_STATUS_ERRKEY | HA_STATUS_NO_LOCK);
    DBUG_RETURN(table->file->errkey);
  }


which results in a more correct error via the partitioning handler 
ha_partition.

So this change makes the server report error ER_DUP_ENTRY (String from 
ER_DUP_ENTRY_WITH_KEY_NAME) with specified entry and index instead of 
the more general ER_DUP_KEY.

Since MTR does not output the error number, there is no way to see if 
the error message changed or if it was another error.

The change was allowed in the test because the test was written to 
accept both ER_DUP_KEY and ER_DUP_ENTRY as valid errors.

So I would just say that your (Guilhem) test update is proper, and 
should be accepted.


For more details please look at BUG#38719.


Regards
Mattias

Guilhem Bichot wrote:
> Hello Mattias,
> 
> There is a test named 
> mysql-test/suite/parts/r/partition_alter2_1_maria.result. It's roughly a 
> copy of
> mysql-test/suite/parts/r/partition_alter2_1_myisam.result.
> After I merged 5.1-main into 5.1-maria a few weeks ago, the maria test 
> started failing; I then fixed its result file in the commit mail below. 
> Monty then saw this commit and protested (see below).
> As you initiated the error message change originally (BUG#38719), I am 
> passing his comments to you.
> If you wish to reply to him, note the cc:maria@stripped.
> Thank you.
> 
> -------- Message original --------
> Sujet: re: bzr commit into MySQL/Maria:mysql-maria branch (guilhem:2741)
> Date: Sun, 19 Apr 2009 03:33:54 +0300
> De: Michael Widenius <michael.widenius@stripped>
> Répondre à :: monty@stripped
> Pour :: Guilhem Bichot <guilhem@stripped>
> Copie à :: maria@stripped
> Références: <20090401100648.90FEE28D18@stripped>
> 
> 
> Hi!
> 
>>>>>> "Guilhem" == Guilhem Bichot <guilhem@stripped> writes:
> 
> Guilhem> #At bzr+ssh://bk-internal.mysql.com/bzrroot/server/mysql-maria/ 
> based on revid:guilhem@stripped
> Guilhem>  2741 Guilhem Bichot    2009-04-01
> Guilhem>       fix for simple test failures
> 
> Guilhem>     modified:
> Guilhem>       mysql-test/suite/parts/r/partition_alter2_1_maria.result
> Guilhem>       mysql-test/suite/parts/r/partition_alter2_2_maria.result
> Guilhem> mysql-test/suite/parts/r/partition_auto_increment_maria.result
> Guilhem> === modified file 
> 'mysql-test/suite/parts/r/partition_alter2_1_maria.result'
> Guilhem> --- a/mysql-test/suite/parts/r/partition_alter2_1_maria.result 
> 2008-11-21 14:21:50 +0000
> Guilhem> +++ b/mysql-test/suite/parts/r/partition_alter2_1_maria.result 
> 2009-04-01 10:06:41 +0000
> Guilhem> @@ -3971,7 +3971,7 @@ INSERT INTO t1 (f_int1, f_int2, f_char1,
> Guilhem>  SELECT f_int1, f_int1, CAST(f_int1 AS CHAR),
> Guilhem>  CAST(f_int1 AS CHAR), 'delete me' FROM t0_template
> Guilhem>  WHERE f_int1 IN (2,3);
> Guilhem> -ERROR 23000: Can't write; duplicate key in table 't1'
> Guilhem> +ERROR 23000: Duplicate entry '2-2' for key 'uidx1'
> 
> Looks like someone changed the arguments for an error message, which
> is something one should *never* do!
> 
> This breaks one of the golden rules that allows one to just replace a
> mysqld binary (in case of failures); With changes like this one has
> also to replace the error message files.
> 
> To do this in a GA release is unheard of and the change should be
> reverted immediately!
> 
> The right way to do this would be to create a new error message with
> the new arguments.
> 
> I also don't understand why one delete the table name from the error
> message. For many cases it's even more important than the key name.
> 
> Regards,
> Monty
>