Comme indiqué dans DatabaseSchema_pgsql :: changeField et dans db_change_field () :
REMARQUE IMPORTANTE: pour maintenir la portabilité de la base de données, vous devez recréer explicitement tous les index et clés primaires qui utilisent le champ modifié.
Cela signifie que vous devez supprimer toutes les clés et tous les index concernés avec db_drop_ {primary_key, unique_key, index} () avant d'appeler db_change_field (). Pour recréer les clés et les index, passez les définitions de clés comme argument $ new_keys facultatif directement à db_change_field ().
Par exemple, supposons que vous ayez:
$schema['foo'] = array(
'fields' => array(
'bar' => array('type' => 'int', 'not null' => TRUE)
),
'primary key' => array('bar')
);
et vous voulez changer foo.bar pour être de type série, en le laissant comme clé primaire. La séquence correcte est:
db_drop_primary_key($ret, 'foo');
db_change_field($ret, 'foo', 'bar', 'bar',
array('type' => 'serial', 'not null' => TRUE),
array('primary key' => array('bar'))
);
Un code similaire est rapporté pour Drupal 7.
Gardez à l'esprit que, d'après mon expérience, vous ne pouvez pas supprimer une clé primaire qui utilise un champ série. Sur Drupal 6, j'ai eu une erreur à chaque fois que j'essayais de faire ça; Je n'ai pas essayé ça sur Drupal 7.
En dehors de cela, je ne connais aucun autre problème que vous pourriez avoir avec les index de base de données.
À propos de l'ajout d'un index à une table de base de données créée à partir d'un autre module, je ne suggère pas de le faire, car:
- Un module ne supprime pas d'index pour un champ en cours de modification, si le module lui-même n'a pas créé cet index. Il ne serait pas possible pour le module de faire cela car il ne connaît pas le nom de l'index.
- La modification d'une table de base de données créée par un autre module n'est jamais une bonne idée, même dans le cas où le module est un module de base. S'il existe un autre module qui modifie la même table, comment les modules pourraient-ils gérer tout conflit qu'ils ont les uns avec les autres, ou avec les modifications que le module principal appliquerait à sa propre base de données?
Si la table de base de données est créée à partir d'un autre module (un module principal ou un module tiers), je suggère d'ouvrir une demande de fonctionnalité pour le module, fournissant un cas d'utilisation pour l'utilisation d'un nouvel index; en cas de problème de performances, l'ajout d'un index peut être la chose à faire.
Si vous comptez ajouter un index à une table créée à partir d'un autre module sur votre propre site, préparez-vous aux modifications que vous devez apporter à votre module personnalisé chaque fois que le module est mis à jour et avant de l'installer sur votre propre site .
C'est vous qui pouvez décider si le travail supplémentaire vaut la performance que vous obtenez. Personnellement, je ne pense pas que cela en vaille la peine.