MediaWiki database policy/fr

Cette page décrit le code officiel des règles de la base de données MediaWiki. Il a été approuvé en décembre 2019 via le processus des RFC TechCom par la RFC T220056.

Requêtes dans la base de données

 * Tout code nouveau qui envoie des requêtes SQL à partir de Mediawi ne doit générer aucun avertissement en mode strict MariaDB / MySQL (d'après la RFC T112637).
 * WMF va activer le mode strict MariaDB / MySQL (T108255), qui sera dans tous les cas le mode par défaut de MySQL 5.7. Avant cela, le code doit être exempt de tout avertissement.
 * Le code qui accède à la base de données doit être compatible avec les modes SQL de MySQL suivants :
 * (équivalent à : )
 * Le code de la base de données doit être compatible avec les anciennes versions des bases comme indiqué dans les contraintes d'installation MediaWiki pour le serveur de bases de données. Néanmoins les améliorations de performances qui ne s'appliquent uniquement qu'aux versions supportées les plus récentes (ou celles par défaut, ou largement recommandées par défaut) doivent être favorisées par rapport à celles qui concernent les versions non supportées.
 * Les requêtes non déterministes ainsi que les commandes non sécurisées sur le binlog doivent être évitées parce qu'elles risquent de renvoyer ou d'écrire des résultats différents dans un environnement répliqué. Ce dernier cas peut être détecté par les avertissements concernant le binlog et dont le texte est « [Warning] Unsafe statement written to the binary log using statement format since BINLOG_FORMAT = STATEMENT ». Cela comprend  lorsqu'une clé d'auto-incrémentation est utilisée,    sans , et l'utilisation de fonctions non déterministes telles que  . Informations supplémentaires ici.
 * Les requêtes non déterministes ainsi que les commandes non sécurisées sur le binlog doivent être évitées parce qu'elles risquent de renvoyer ou d'écrire des résultats différents dans un environnement répliqué. Ce dernier cas peut être détecté par les avertissements concernant le binlog et dont le texte est « [Warning] Unsafe statement written to the binary log using statement format since BINLOG_FORMAT = STATEMENT ». Cela comprend  lorsqu'une clé d'auto-incrémentation est utilisée,    sans , et l'utilisation de fonctions non déterministes telles que  . Informations supplémentaires ici.

Modifications du schéma

 * Chaque nouvelle table doit avoir une clé primaire. Lorsqu'un candidat ne peut être créé pour une clé primaire (par exemple, quand toutes les colonnes peuvent être répétées), il faut ajouter une colonne séparée d'auto-incrémentation, ou un autre champ arbitraire (selon le cas).
 * Les clés primaires ainsi que les champs qui les référencent, doivent être non signés, afin d'augmenter les valeurs maximales.

Corrections dans la base de données
Si vous modifiez le schéma de la base de données, observez les règles suivantes :


 * Update the installer – Update  and add an appropriate SQL patch file to  . The naming convention, if you're adding a field, is  . If you're removing a field, it's  . If you're adding a table, it's  . Look at the commit history of   to find examples of how it's done. If you're adding a bunch of fields to the same table, make all those changes in one query in one patch file.
 * Make your schema change optional – All schema changes must go through a period of being optional. Some examples:
 * Instead of changing the format of a column, create a new column, make all writes happen to the old and new column (if it exists), and deprecate use of the old column. Check if the new column exists before blindly assuming that it does. Only eliminate support for the old column after it's clear the schema migration has completed and there's no chance that we'll need to roll back to the old version of the software. If this doesn't seem feasible, send mail to Wikitech-l asking for advice.
 * You could set your new feature to only work if a config option is set to true, and set the option to false by default. Then the commit can be safely deployed before the schema change is made. To deploy your feature to the Wikimedia cluster, file a ticket in Phabricator in the relevant project with the  tag. Once you've confirmed the change has been made, you can remove the config option to enable your feature.
 * Note that this means your schema change should be optional in code - for wikimedia deployments, it is expected that every wiki with the relevant database table(s) will have the schema change applied to them. If you need different schema for different wikis, then apply the change using an extension and creating new tables dependent on that extension.

Il y a des cas où la règle « rendez facultatives vos modifications de schéma » serait contraire du point de vue des performances ou logistique. Néanmoins de telles modifications du schéma restent rares si on veut commencer par elles et doivent faire l'objet d'importantes discussions sur la liste de diffusion wikitech-l. Dans le cas où il est impossible de rendre facultatives les modifications de votre schéma, l'écriture de scripts pour restituer l'état antérieur reste discutable.


 * Rechercher les entrées venant d'un administrateur de base de données de la WMF – MediaWiki is deployed to Wikimedia websites every week, and it takes considerable planning to apply schema changes to MySQL-based sites the size of Wikipedia. Jaime Crespo (jcrespo on LDAP, jynus on irc and Manuel Arostegui, marostegui) are the best people to add to database reviews. In most cases, input is just needed on the logistics of the change.
 * Testez vos modifications sur Bêta - en particulier, une erreur habituelle consiste à modifier les indexes et la définition des colonnes qui résulterait en différents plans de requêtes. Try to test the generated queries' plan with tools such as EXPLAIN; not doing so could mean that, when scaled to production, queries that only take 1 second locally, they pileup on production when they receive much more traffic and have larger tables.