Rentrant de vacances et d'humeur badine, j'ai décidé de mettre à jour
un site en production en choisissant la version du jour (site qui
était précédemment en 1.6.x).
Quelle ne fut pas ma surprise (non, en fait, pas tellement surpris, je
me disais bien qu'il y aurait une couille) de voir qu'après la mise à
jour de la base, le site ne fonctionnait pas bien, notamment en raison
de l'absence de la colonne "lang" dans la table "spip_articles".
Évidemment, le problème était une absence de permission pour "ALTER TABLE",
problème vite résolu en rabaissant la version enregistrée dans
"spip_meta" et en relançant la mise à jour. Toutefois, SPIP ne m'a pas
averti d'un problème.
Pour éviter ce genre d'incidents, peut-être que SPIP pourrait vérifier
que la dernière modification de structure a bien eu lieu (pas en
vérifiant le résultat de l'opération ALTER TABLE, mais en vérifiant la
présence du dernier champ créé ou modifié en faisant une requête); en
cas de problème, il poourrait avertir, et ne pas modifier le numéro de
version dans les métadonnées.
Rentrant de vacances et d'humeur badine, j'ai décidé de mettre à jour
un site en production en choisissant la version du jour (site qui
était précédemment en 1.6.x).
Quelle ne fut pas ma surprise (non, en fait, pas tellement surpris, je
me disais bien qu'il y aurait une couille) de voir qu'après la mise à
jour de la base, le site ne fonctionnait pas bien, notamment en raison
de l'absence de la colonne "lang" dans la table "spip_articles".
Évidemment, le problème était une absence de permission pour "ALTER TABLE",
Oui, le r@s aussi avait ce problème.
problème vite résolu en rabaissant la version enregistrée dans
"spip_meta" et en relançant la mise à jour. Toutefois, SPIP ne m'a pas
averti d'un problème.
Pour éviter ce genre d'incidents, peut-être que SPIP pourrait vérifier
que la dernière modification de structure a bien eu lieu (pas en
vérifiant le résultat de l'opération ALTER TABLE, mais en vérifiant la
présence du dernier champ créé ou modifié en faisant une requête); en
cas de problème, il poourrait avertir, et ne pas modifier le numéro de
version dans les métadonnées.
Normalement ça doit être possible ; on fait quoi en cas de problème de mise
à jour ? On indique juste "problème de mise à jour vers $spip_version à
l'étape $spip_current " et on fait exit() ?
> Pour éviter ce genre d'incidents, peut-être que SPIP pourrait vérifier
> que la dernière modification de structure a bien eu lieu (pas en
> vérifiant le résultat de l'opération ALTER TABLE, mais en vérifiant la
> présence du dernier champ créé ou modifié en faisant une requête); en
> cas de problème, il poourrait avertir, et ne pas modifier le numéro de
> version dans les métadonnées.
Voilà, c'est codé (mais si quelqu'un veut passer dans le code de inc_base
pour répérer les tests à faire, welcome).
L'idée est de remplacer, aux endroits critiques, la construction
maj_version (1.709, spip_query("SELECT lang FROM spip_articles") OR spip_query("SELECT lang FROM spip_rubriques"));
ça va ?
Evidemment, quand on met plusieurs tests les uns à la suite des autres, ça
n'est pas OR mais AND (ou &&, je ne sais pas la différence)
en général on confond les 2 pourtant ce ne sont pas les meme operations.
- l'un porte sur une operation qui rend un booleen (true|false)
- l'autre est un opérateur qui agit sur les bits. Mais si on passe des
entiers, des chaines, des chars aux operateurs binaires, ca fonctionne
tres bien ; sauf que le resultat obtenu n'est pas forcement celui attendu.
