Voilà, voilà... Fin de l'aventure...

 

Fermeture de kolossaldrupal.org dans...


Bonjour tout le monde,

Drupal évolue, les versions changent et Kolossaldrupal.org était essentiellement consacré à la version 6 de Drupal.

Autant dire que les infos présentées ici commencent à dater...

Faute de temps, je ne peux plus garder le site Kolossaldrupal à jour...

Je vous aurais bien proposé de reprendre le flambeau mais... c'est tellement simple de nos jours de se faire son propre site à soi...Pourquoi s'embêter alors ? :-)

Ce site restera donc en l'état, tel qu'il était en 2011...

Ah la la ! Cela ne nous rajeunit pas !

Manuel Vila - Avril 2016

SQL : conventions de programmation

Référence sur drupal.org : 14 Mars 2009 – 22h26 - http://drupal.org/node/2497


N’utilisez pas de mots-clé réservés

N’utilisez pas les mots-clé de (ANSI) SQL / MySQL / PostgreSQL / MS SQL Server / …, les mots-clés pour les noms de colonnes, tables. Même si ça marche bien avec votre installation de xxSQL, ça peut ne pas marcher du tout avec d’autres, ou avec d’autres bases de données.

Quelques références :

Quelques mots-clés fréquemment mal-employés : TIMESTAMP, TYPE, TYPES, MODULE, DATA, DATE, TIME, ...

Voir aussi [bug] SQL Reserved Words.

Mise en capitales et données fournies par l’utilisateur

  • Écrivez les mots-clé SQL en CAPITALES. Ce n’est pas une suggestion. La couche d’abstraction DB de Drupal échouera si cette convention n’est pas appliquée.
  • Écrivez les noms des colonnes et des contraintes en minuscules
  • Entourez chaque nom de table par des accolades {} (cela permet à Drupal de préfixer le nom des tables).
  • Les arguments variables (qui sont souvent fournis par l’utilisateur) ne doivent pas se trouver dans le corps de la requête mais passés en tant que paramètres séparés à db_query(), db_query_range(), et db_query_temporary(), etc.
    A la place, le corps de la requête doit contenir des paramètres substituables (placeholders) en précisant le type de l’argument (<?php%d|%s|%%|%f|%b?>). Cela garantit que les données seront correctement échappées et évite les attaques par injection de code SQL.
  • Éviter les attaques par injection de code SQL est facile : db_query fournit une façon  d’utiliser les requêtes paramétrées. Les fonction de bases de données de Drupal remplace les paramètres avec les arguments correctement echappés, dans l’ordre de passage :
    • %d – entiers
    • %f – flottants
    • %s – chaînes, entourées de ’’
    • %b  - données binaires, ne pas encadrer de guillemets
    • %% - remplacé par %
  • Consultez Database Access
  • Les arguments littéraux (constantes) peuvent être soit inclus dans le corps de la requête, soit passés comme arguments.
  • Toute chaîne littérale ou paramètre de type %s doit être encadré par des guillemets simples : ' . N’utilisez jamais de guillemets doubles.

Exemple :


<?php
db_query
("INSERT INTO {filters} (format, module, delta, weight) VALUES (%d, 'php', 0, 0)"$format);
?>

Remarque : depuis Drupal 6.x, les déclarations de tables et de contraintes (comme les clés primaires, clés uniques, indexes) doivent toujours être manipulés par Schema API, qui résout automatiquement les questions de compatibilité inter-bases de données.

Nommage

  • Pour les noms de tables, utilisez des nom au singulier car ils décrivent l’entité que représente la table. Drupal 6.x utilisait autant le singulier que le pluriel et cette convention a été modifiée pour Drupal 7.x.
  • Nommez chaque contrainte vous-même (primaire, clé étrangère, clé unique). Sinon, dans les messages d’erreurs,  vous risquez de voir des noms bizarres générés par le système. Ceci s’est produit avec la table moderation_roles qui avait défini une clé sans nom en tant que KEY(mid). Ce qui, lors d’un dump, a donné KEY mid (mid), provoquant une erreur de syntaxe puisque mid() est une fonction mysql (voir [bug] mysql --ansi cannot import install database).
  • Les noms d’index doivent commencer par le nom de la table à laquelle ils s’appliquent. Par exempel : INDEX users_sid_idx.

Remarque : depuis Drupal 6.x, les déclarations de table et de contraintes doivent toujours être gérées par l’API Schema.

Configurez votre serveur de base de données pour le respect des normes

Beaucoup de serveurs de bases de données utilisent une extension pour le SQL standard. Cependant, plusieurs d’entre eux peuvent être configurés pour s'exécuter dans plus d’un standard. Chaque développeur est encouragé à utiliser le mode le plus conforme à la norme pour éviter le codage fantaisiste et des problèmes de compatibilité.

MySQL

Activez les mode ANSI et Strict.

Merci de nous aider à compléter cette liste de serveur de bases de données !

Références

Indentation

Drupal n’a pas de méthodes normalisée pour l’indentation ou la mise en forme de requêtes SQL longues sur plusieurs lignes. Parmi ces méthodes, on a :


<?php
if (!(db_query(
  
"
    INSERT INTO {mlsp_media_file_type}
    SET extension   = '%s',
    attributes      = '%s'
  "
,
  
$file_type_entry['extension'],
  
$selected_attributes
))) {
  
$errors TRUE;
}
?>

ou


<?php
$sql 
"SELECT t.*, j1.col1, j2.col2"
" FROM {table} AS t"
" LEFT JOIN {join1} AS j1 ON j1.id = t.jid"
" LEFT JOIN {join2} AS j2 ON j2.id = t.jjid"
" WHERE t.col LIKE '%s'"
" ORDER BY %s"
;
$result db_query($sql'findme''t.weight');
?>