problème de strip *automatique* dans mysql... - Page 1

salut,

j'ai un problème de strip automatique de string quand j'update une table MySQL :

mysql> show columns from MyTable ;
+-----------------------+-------------+------+-----+---------+----------------+
| Field                 | Type        | Null | Key | Default | Extra          |
+-----------------------+-------------+------+-----+---------+----------------+
| Id                    | int(11)     | NO   | PRI | NULL    | auto_increment | 
.                       .             .      .     .         .                .
.                       .             .      .     .         .                .
| TypeLoadingManagement | varchar(50) | YES  |     | NULL    |                | 
.                       .             .      .     .         .                .
.                       .             .      .     .         .                .
+-----------------------+-------------+------+-----+---------+----------------+
7 rows in set (0.00 sec)

mysql> update MyTable set TypeLoadingManagement='        X       ' ;
Query OK, 14 rows affected (0.00 sec)
Rows matched: 14  Changed: 14  Warnings: 0

mysql> select TypeLoadingManagement t from MyTable ;
+-----------+
| t         |
+-----------+
|         X | 
|         X | 
|         X | 
|         X | 
|         X | 
|         X | 
|         X | 
|         X | 
|         X | 
|         X | 
|         X | 
|         X | 
|         X | 
|         X | 
+-----------+
14 rows in set (0.00 sec)

voilà, où sont passés les caractères ' ' après le 'X' ???


Franchement je ne comprend pas, vu qu'en plus ça fonctionne très bien dans une autre table !

mysql> show columns from MyTable2 ;
+-----------------------+-------------+------+-----+---------+----------------+
| Field                 | Type        | Null | Key | Default | Extra          |
+-----------------------+-------------+------+-----+---------+----------------+
| Id                    | int(11)     | NO   | PRI | NULL    | auto_increment | 
.                       .             .      .     .         .                .
.                       .             .      .     .         .                .
| TypeLoadingManagement | varchar(50) | YES  |     | NULL    |                | 
.                       .             .      .     .         .                .
.                       .             .      .     .         .                .
+-----------------------+-------------+------+-----+---------+----------------+
9 rows in set (0.02 sec)


mysql> update MyTable2 set TypeLoadingManagement='        X       ' ;
Query OK, 47 rows affected (0.00 sec)
Rows matched: 47  Changed: 47  Warnings: 0

mysql> select TypeLoadingManagement t from MyTable2 ;
+------------------+
| t                |
+------------------+
|         X        | 
|         X        | 
|         X        | 
|         X        | 
|         X        | 
|         X        | 
|         X        | 
|         X        | 
|         X        | 
|         X        | 
|         X        | 
|         X        | 
|         X        | 
|         X        | 
|         X        | 
|         X        | 
|         X        | 
|         X        | 
|         X        | 
|         X        | 
|         X        | 
|         X        | 
|         X        | 
|         X        | 
|         X        | 
|         X        | 
|         X        | 
|         X        | 
|         X        | 
|         X        | 
|         X        | 
|         X        | 
|         X        | 
|         X        | 
|         X        | 
|         X        | 
|         X        | 
|         X        | 
|         X        | 
|         X        | 
|         X        | 
|         X        | 
|         X        | 
|         X        | 
|         X        | 
|         X        | 
|         X        | 
+------------------+
47 rows in set (0.00 sec)

si vous avez des idées...
merci d'avance

t'as essayé avec des doubles quotes?

sinon... joker

non, mais en fait j'étais en train de lire que c'est plus ou moins le comportement normal du varchar sous mysql (mais dans ce cas ça devrait stripper dans la 2eme table aussi...)

http://dev.mysql.com/doc/refman/5.1/en/char.html
If a given value is stored into the CHAR(4) and VARCHAR(4) columns, the values retrieved from the columns are not always the same because trailing spaces are removed from CHAR columns upon retrieval. The following example illustrates this difference:

mysql> CREATE TABLE vc (v VARCHAR(4), c CHAR(4));
Query OK, 0 rows affected (0.01 sec)

mysql> INSERT INTO vc VALUES ('ab  ', 'ab  ');
Query OK, 1 row affected (0.00 sec)

mysql> SELECT CONCAT('(', v, ')'), CONCAT('(', c, ')') FROM vc;
+---------------------+---------------------+
| CONCAT('(', v, ')') | CONCAT('(', c, ')') |
+---------------------+---------------------+
| (ab  )              | (ab)                |
+---------------------+---------------------+
1 row in set (0.06 sec)

C'est complètement débile comme comportement !
Et ça n'explique pas pourquoi ça fonctionne dans la seconde table, d'ailleurs...

http://www.mysqlperformanceblog.com/2006/11/27/trailing-spaces-in-mysql/
In the past life was easy in MySQL. Both CHAR and VARCHAR types meant the same, only being difference in the sense of fixed or dynamic row length used. Trailing spaces were removed in both cases.

With MySQL 5.0 however things changed so now VARCHAR keeps trailing spaces while CHAR columns do not any more. Well in reality CHAR columns are padded to full length with spaces but it is invisible as those trailing spaces are removed upon retrieval. This is something you need to watch both upgrading to MySQL 5.0 as well as designing your applications - you should keep into account if you mind trailing spaces stored choosing VARCHAR vs CHAR in addition to fixed length vs dynamic level rows and space spent for column size counter.
There is more fun stuff with trailing spaces. When comparison is done trailing spaces are always removed, even if VARCHAR column is used which is pretty counterintuitive. So “a “=”a”=”a ” for all textual column types - CHAR, VARCHAR, TEXT. BLOB is exception it will preserve trailing spaces and use them in comparison.

et

http://www.issociate.de/board/post/153577/Strings_with_trailing_blanks_-_where_did_I_goof?.html
If it's important to keep the trailing spaces you can use the TINYTEXT,
or TINYBLOB types instead.

m'enfin ça n'explique toujours pas pourquoi ça fonctionne dans la seconde table

bah oué, ça devrait marcher avec varchar et stripper avec char

les deux tables ont le même moteur ? (innodb/myisam)

les deux tables ont le même interclassement ?

après un dump j'ai ça :

CREATE TABLE `MyTable2` (
  [...]
) ENGINE=MyISAM AUTO_INCREMENT=52 DEFAULT CHARSET=latin1;


CREATE TABLE `MyTable1` (
  [...]
) ENGINE=MyISAM AUTO_INCREMENT=23 DEFAULT CHARSET=latin1;

donc pour le moteur je dirais oui, pour l'interclassement je n'en ai aucune idée : je ne sais même pas ce que c'est !

en gros "interclassement" peut se résumer à "charset & code page" comme par exemple utf8_general_ci pour la page par défaut de l'utf8 en case insensitive

ok merci.
ben ça a l'air bon alors, non ?

oui, ça a en effet l'air d'être la même chose

étrange...