[spip-dev] MySql : upgrade DB d'une version 1.7.2 vers un CVS 1.8.2

Après avoir expérimenté qq problèmes en passant au CVS 1.8 sur des sites
existants, je me suis rendu compte que le script d'upgrade de la base de
données ne fait que créer les nouvelles tables qui n'existent pas, mais ne
modifie pas les champs qui doivent être modifiés.

Au passage cela m'a fait découvrir cet excellent outil :
http://www.mysqldiff.org/

Voici le fruit de mes expérimentation pour ceux que ça intéresse (!!! à
utiliser sans aucune garantie de résultat : faites vos backups avant
d'essayer... !!!)

Ca c'est pas normal du tout : quelqu'un peut confirmer ce bug ?

@ Aly <aly@nepadsn.org> :

Après avoir expérimenté qq problèmes en passant au CVS 1.8 sur des sites
existants, je me suis rendu compte que le script d'upgrade de la base de
données ne fait que créer les nouvelles tables qui n'existent pas, mais ne
modifie pas les champs qui doivent être modifiés.

Au passage cela m'a fait découvrir cet excellent outil :
http://www.mysqldiff.org/

Voici le fruit de mes expérimentation pour ceux que ça intéresse (!!! à
utiliser sans aucune garantie de résultat : faites vos backups avant
d'essayer... !!!)

===============================================================

# script SQL d'upgrade de 1.7.2. vers CVS1.8.2

ALTER TABLE spip_articles
    ADD url_propre varchar(255) NOT NULL DEFAULT '' AFTER url_site,
    MODIFY id_article bigint(21) NOT NULL DEFAULT '' auto_increment,
    MODIFY id_rubrique bigint(21) NOT NULL DEFAULT '0',
    MODIFY id_secteur bigint(21) NOT NULL DEFAULT '0',
    ALTER accepter_forum SET DEFAULT '',
    MODIFY auteur_modif bigint(21) NOT NULL DEFAULT '0',
    MODIFY id_trad bigint(21) NOT NULL DEFAULT '0',
    ADD INDEX idx (idx),
    ADD INDEX url_propre (url_propre);

ALTER TABLE spip_auteurs
    MODIFY pass tinytext NOT NULL DEFAULT '',
    MODIFY alea_actuel tinytext NOT NULL DEFAULT '',
    MODIFY alea_futur tinytext NOT NULL DEFAULT '',
    ADD INDEX idx (idx);

ALTER TABLE spip_breves
    ADD url_propre varchar(255) NOT NULL DEFAULT '' AFTER extra,
    ADD INDEX idx (idx),
    ADD INDEX url_propre (url_propre);

ALTER TABLE spip_forum
    ADD id_thread bigint(21) NOT NULL DEFAULT '0' AFTER id_parent;

ALTER TABLE spip_mots
    ADD url_propre varchar(255) NOT NULL DEFAULT '' AFTER idx,
    ADD INDEX idx (idx),
    ADD INDEX url_propre (url_propre);

ALTER TABLE spip_referers
    ADD visites_veille int(10) unsigned NOT NULL DEFAULT '0' AFTER
visites_jour;

ALTER TABLE spip_rubriques
    ADD url_propre varchar(255) NOT NULL DEFAULT '' AFTER extra,
    ADD statut_tmp varchar(10) NOT NULL DEFAULT '' AFTER url_propre,
    ADD date_tmp datetime NOT NULL DEFAULT '0000-00-00 00:00:00' AFTER
statut_tmp,
    MODIFY id_rubrique bigint(21) NOT NULL DEFAULT '' auto_increment,
    MODIFY id_parent bigint(21) NOT NULL DEFAULT '0',
    MODIFY id_secteur bigint(21) NOT NULL DEFAULT '0',
    MODIFY id_import bigint(20) NULL DEFAULT '0',
    ADD INDEX idx (idx),
    ADD INDEX url_propre (url_propre);

ALTER TABLE spip_signatures
    ADD INDEX idx (idx);

ALTER TABLE spip_syndic
    ADD INDEX idx (idx);

ALTER TABLE spip_versions
    ADD champs text NOT NULL DEFAULT '' AFTER permanent;

===========================================================

Ceci dit, il reste du boulot au niveau du suivi des révisions (il me semble
qu'au moins un script php pour traiter les données soit nécessaire pour
passer du codage dans "spip_versions" de 4 champs à 1 seul champ, comme je
l'avais évoqué dans le post "suivi des révisions ?" du 14/12)

Aly

_______________________________________________
liste: http://listes.rezo.net/mailman/listinfo/spip-dev
doc: http://www.spip.net/
cvs: http://www.spip.net/spip-dev/devel/
irc://irc.freenode.net/spip

-- Fil

> Après avoir expérimenté qq problèmes en passant au CVS 1.8 sur des sites
> existants, je me suis rendu compte que le script d'upgrade de la base de
> données ne fait que créer les nouvelles tables qui n'existent pas, mais ne
> modifie pas les champs qui doivent être modifiés.

En réalité ce problème ne devrait se poser que pour la table spip_versions,
à cause d'un oubli, que je corrige maintenant.

-- Fil

Salut,

Bon en fait ça m'a fait découvrir qu'on pouvait aussi utiliser les dump xml
pour s'en sortir autrement : laisser le script d'install créer complètement
la base - vierge donc - et importer par dessus depuis l'interface d'admin un
dump xml qui n'apporte que les données sans toucher à la structure.
Ca marche bien, sauf qu'il faut se retaper à la main les méta, les stats,
les dicos... mais au moins la structure est propre (et tout fonctionne bien)

Merci, et félicitations au passage pour l'intégration du travail d'Emmanuel
: on a des clients super contents du passage à la 1.8.2, ils ont bien senti
l'amélioration des performances, et trouvent que l'interface admin est
beaucoup plus agréable et plus ergonomique ;)))
Aly

Senti ou mesuré ? C'est très difficile d'avoir des mesures fiables. A part les TOTAL_BOUCLE appels au serveur pour calculer TOTAL_BOUCLE dont j'ai déjà parlé, je ne prétends rien dans l'amélioration du temps calcul, et à peine plus pour le gain en place.
Mais si tu as des mesures précises je suis preneur.

      Emmanuel

Oui pour le moment c'est 'senti' chez le client, qui a un Lan un peu
compliqué : c'est une banque... ça pourrait donc tt à fait venir d'autre
chose, mais je vais essayer de faire des tests précis avec ab ce soir
(comparatif 1.7.2 versus 1.8.2 avec la 'même' BD : même données mais
structure propre à la version donc légèrement différente).

@++
Aly

"Déesse A." <esj@vertsdesevres.net> a écrit dans le message de news:
5B4C7D0A-5361-11D9-B286-000A95CA8270@vertsdesevres.net...

résultats du benchmark (taille de la page servie 20.8 Ko / 21302 octets):

- avec recalcul des pages :
1.8.2CVS ab -c 1 -n 100
"http://localhost/aacb4/plan.php3?lang=en&recalcul=oui" 98 ms
(moyenne)
1.7.2 ab -c 1 -n 100
"http://localhost/aacb3/plan.php3?lang=en&recalcul=oui" 1231 ms
(moyenne)

- pages servies depuis le cache :
1.8.2CVS ab -c 1 -n 100
"http://localhost/aacb4/plan.php3?lang=en"
96 ms (moyenne)
1.7.2 ab -c 1 -n 100
"http://localhost/aacb3/plan.php3?lang=en"
52 ms (moyenne)

J'ai choisi le plan car il contient beaucoup de boucles, et filtre sur la
langue.
On voit que la nouvelle version est plus constante et le recalcul de la page
n'influe presque pas sur le temps total, par contre l'ancienne version livre
plus vite ce qui vient du cache (mais comme l'ordre de temps est inférieur
au dixième de seconde, l'utilisateur ne voit pas la différence).
Mais, sur une page "normale" cad. simple, avec peu de texte, 4.77 Ko (4880
octets), on obtient l'inverse : 8 ms avec la 1.8.2 et 14 ms avec la 1.7.2 ce
qui pourrait sembler plus 'normal'.

J'ai fait les mêmes essais sur une autre machine (là je suis avec apache
1.3/PIV je suis passé sur un céléron avec apache 2) et les rapports sont
tout à fait similaires (c'est globalement plus rapide, mais on a exactement
les mêmes ratios, donc pas de surprise)
J'ai fait des essais avec un autre site calqué sur les squelettes de Booz
(le Bloog) et là les résultats sont plus mitigés encore : il semble que plus
le squelette est complexe et plus le temps d'un recalcul soit proche de
l'ancienne version - voire plus long ! - mais peut-être aussi qu'il faudrait
re-designer le squelette pour tirer profit des nouvelles fonctionnalités ?

Tout ceci me laisse penser qu'il faut faire d'autres tests plus ciblés, pour
mettre en évidence quels sont les facteurs décisifs, essayer de voir
l'influence éventuelle d'inclusions php, etc.

@+
Aly

"Aly" <aly@genesis-net.com> a écrit dans le message de news:
cq9fgr$47g$1@sea.gmane.org...

- avec recalcul des pages :
1.8.2CVS ab -c 1 -n 100
"http://localhost/aacb4/plan.php3?lang=en&recalcul=oui&quot; 98 ms
(moyenne)

Bug: la CVS interdit le recalcul des pages depuis un accès non connecté
admin (va savoir pourquoi) ; et par ailleurs l'url de recalcul a changé. Tu
visais donc le cache. Effectivement ça va plus vite comme ça :slight_smile:

-- Fil

Bug: la CVS interdit le recalcul des pages depuis un accès non connecté
admin (va savoir pourquoi) ; et par ailleurs l'url de recalcul a changé. Tu
visais donc le cache. Effectivement ça va plus vite comme ça :slight_smile:

Par ailleurs il faut peut-être plutôt se pencher sur le recalcul "normal"
d'une page, et non sur le recalcul "forcé", car ce dernier provoque la
recompilation du squelette, et ne correspond donc à rien en situation
réelle. Donc il faut faire tes tests sans ?recalcul, mais avec $delais=0

-- Fil

ok, merci pour les précisions, je reprendrai ça un peu plus tard

Aly

"Fil" <fil@rezo.net> a écrit dans le message de news:
20041222172754.GE16726@rezo.net...

Bug: la CVS interdit le recalcul des pages depuis un accès non connecté
admin (va savoir pourquoi) ; et par ailleurs l'url de recalcul a changé.
Tu
visais donc le cache. Effectivement ça va plus vite comme ça :slight_smile:

Par ailleurs il faut peut-être plutôt se pencher sur le recalcul "normal"
d'une page, et non sur le recalcul "forcé", car ce dernier provoque la
recompilation du squelette, et ne correspond donc à rien en situation
réelle. Donc il faut faire tes tests sans ?recalcul, mais avec $delais=0

-- Fil