Recherche avancée

Sur d’autres sites (10089)

• Anomalie #4342 : Erreur 1071 de mysql : Specified key was too long ; max key length is 1000 bytes

  7 avril 2020

  Une autre piste donnée par b_b sur IRC :

  https://florent.poinsaut.fr/2018/08/17/mysql-mariadb-index-column-size-too-large-the-maximum-column-size-is-767-bytes/ :

  - 767 octets est la limite de préfixe déclaré pour les tables InnoDB dans les versions antérieures à la 5.7 de MySQL et dans les versions antérieurs à la 10.2 de MariaDB.
  - A partir de la version 5.7 de MySQL et la 10.2 de MariaDB, cette limite a été augmentée à 3072 octets.

  => bingo on est en 10.1.41-MariaDB-1 stretch

  - L’encodage (latin1, UTF8, UTF8mb4, etc.) peut jouer sur cette taille. Puisqu’en UTF8 un caractère prend 3 octets, il faut diviser la taille disponible par 3 pour trouver la longueur maximale de préfixe d’index. Et par 4 si on utilise UTF8mb4.

  => re bingo on est en utf8

  Une piste ici :

  global.innodb_large_prefix = 1

  https://stackoverflow.com/a/22873006
  https://github.com/go-gitea/gitea/issues/2979#issuecomment-412607116
  https://answers.launchpad.net/maria/+question/241612

  Amha c’est l’option qu’il nous faut tant qu’on est pas en mariadb > 10.1, sinon il faut passer en mariadb 10.3 cf :

  https://github.com/go-gitea/gitea/issues/2979#issuecomment-421000381

  PS : j’utilise mariadb 10.3 en local et je n’ai pas ce problème.

• Anomalie #4353 : MYSQL 5.7 - Comportement du timestamp vs la variable explicit_defaults_for_timestamp

  1er juillet 2021, par b b

  J’y reviens, on ne peut pas cherry picker non ? Car ça risque de coller le même "version_base" dans la 3.2 et la 4.0. Faut reporter à la main donc ?

• Anomalie #4353 (Nouveau) : MYSQL 5.7 - Comportement du timestamp vs la variable explicit_defaults_...

  17 juin 2019, par Eric Lupinacci

  Suite à une réinstallation de SVP (var_mode) qui supprime les tables et les recrée dans la foulée je me suis rendu compte que le timestamp de la table spip_depots ne se mettait plus à jour automatiquement.
  En cherchant avec Matthieu j’ai noté que chez moi la variable explicit_defaults_for_timestamp était à 1 ce qui ne devait jamais être le cas auparavant et donc provoquait ce dysfonctionnement si la déclaration du champ ne précisait pas la mise à jour automatique : DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP

  En général, j’ai toujours vu les déclarations du type ’maj’ => ’timestamp’ sans rien préciser.

  Ne serait-il pas utile de forcer à la création d’un timestamp le default et le comportement à l’update de façon à se prémunir de ce problème de configuration MYSQL. En plus, une fois créée sans update auto il faut soit un alter table soit recréer la table ce qui est lourd.