Voilà pourquoi j'ai bougé le topic dans la section "discussion" du forum.

Faire 2 upgrade 2 fois de suite ? Absolument pas du tout d'accord, cela ne présente aucun intérêt et pour avoir l'habitude (c'est mon métier) cela serait techniquement très pénible à mettre en place.

Pourquoi 2 upgrades, car j'ai passé sur un site de test la version 1.5.0.orc1 puis la finale... ne sachant pas les différences, j'ai voulu passer les upgrades 2 fois. (pas de soucis si les alters non pas changés, pas d'ajout d'alter, d'update)

De plus, c'est mon métier aussi et je ne suis pas d'accord.
Je fais souvent des patchs de mise à jour (script, base pracle, etc...) et je vous trouve d'un trus de base, c'est depourvoir passer x fois de suite un correctif.
Notamment, pour ces cas:
  o upgrade fais x fois par mégarder
  o upgrade fais x fois car upgrade pas ok (style les champs inutiles des tables ne sont enlévés)
  o arrêt de l'upgrade à la moitié pour x raisons

Je suis, par contre, d'accord sur le fait que des fois c'est pénible à faire mais pour l'utlisateur final c'est des fois plus simple...

Bref, il me semble que c'est assez de dire que c'est sans interêt...

z0rglub a écrit:

Je vais prendre un exemple de ce que certains de mes collègues font pour justement pouvoir passer les scripts SQL X fois : au lieu de faire un "create table", il font "delete"+"insert". Je trouve ça misérable car cela génère des tas d'erreurs dans les logs d'exécution des SQLs.

Je me bats aussi contre ca... les drop avant les create systématiques... ect... je suis ok mais ca c'est le problem de base des scripts de mise à jour (qu'il soit passé 1,2, x fois)

z0rglub a écrit:

En fait, c'est plus que pénible, c'est dangereux.

Passez 2 fois un upgrade par mégarde, c'est dangereux, d'ou le fait de brider les updrade soit en les bridant comme tu as proposé soit en permettant de les passer x fois...

z0rglub a écrit:

Lorsque je suis d'astreinte sur une migration de base d'un client, suite au passage des scripts SQL, j'analyse les logs. Certaines erreurs seront corrigeables en direct, d'autre me feront dire qu'on annule la migration car le processus a échoué. Il est inimaginable que je propose de rejouer les scripts d'upgrade.

Si tas migration a planté, comment tu fais pour remettre au carré la base par la suite... à la mimine? ou du repasse le patch?

z0rglub a écrit:

Pour revenir sur PhpWebGallery, sur lequel une erreur n'a pas du tout les mêmes conséquences qu'à mon travail...

Sauf que tout les utilisateus de pwg ne sont pas forcement des pros de l'informatique et que si un upgrade plante que le site fonctionne plus... ils sont un peu emmerdés...

z0rglub a écrit:

Ce qui serait intéressant, c'est que le script d'upgrade puisse connaître la version de la base de données qu'il va mettre à jour pour accepter de poursuivre ou non. Imagines que upgrade.php te propose de mettre à jour une 1.3.4 ou une 1.4.0 et que tu te trompes en choisissant 1.3.4 alors que tu as une 1.4.0, tu devrais te faire jeter.

Ok pour ca... on pourrait même faire un upgrade unique qui fassent plusieurs étapes 1.3.0 vers 1.4.0 puis vers 1.5.0 par exemple.

z0rglub a écrit:

Le problème de fond de ce topic, c'est que les scripts d'upgrade peuvent être buggés... et comme ils sont inclus dans la release, une nouvelle version du script d'upgrade signifie augmentation du numéro de release :-/ Avant, je livrai les scripts d'upgrade séparémment, mais pour l'utilisateur final, c'est mieux d'avoir un seul paquet à télécharger.

Justement les scripts d'upgrade sont à tester à corriger dans les orcxx... dans les forums, tu dis que tu ne propose pas de méthode ou de script pour passer de 1.5.0.orc2 à la finale... un script d'upgrade (x fois) aurait permis de supprimer les colonnes que tu partes de la 1.4.1 ou de 1.5.0.OCR2...

z0rglub a écrit:

D'ailleurs, le script d'upgrade 1.4.x vers 1.5.0 est légèrement buggé : bug 209 : Le schema n'est pas convenablement mis à jour

C'était d'ailleurs ma première question ;-)

Bref, on est pas vraiment d'accord (ca change) mais nos points se discutent et dépendent des projets.
Moi, je préfére les upgrade x fois béton (j'ai pas envie de citrouille de 3 tonnes)
sinon il faut un upgrade qui indique que les données sont mises à jour pour éviter que l'utilisateur se retrouve devant une erreur sql imcompréhensible...

Si par hasard, tu as besoin de l'aide pour faire des upgrade le plus béton possible, je veux bien m'y coller un peu (même si le php, je connais pas vraiment voir pas du tout)

z0rglub a écrit:

Si tu pouvais regarder upgrade_feed.php sur trunk (ou BSF, 2 noms pour désigner la même chose) et me donner ton avis, ça m'intéresse.

Voila, je viens de regarder vite fait, sympa le systeme de mise à jour avec détection des parties déjà utlisés, ca va être pratique.

Mais des petites questions me viennent:
  o pourquoi database pour les noms de fichiers? Je penses que ce systéme peut être appliqués pour tout type de mise à jour (database, fichier include, fichier, ....)
  o il faudrait pe pouvoir définir un ordre pour faire les updates et bloquer les mises à jour en cas de soucis... au début, j'avais pensé qu'on pouvait utiliser la nouvelle table "upgrade" (champs order par exemple) mais pas cool il faut definir la liste dans la table donc une mise à jour en base avant les update... Par contre, avec un système d'inclusion, on peut faire les deux:
    > ajout dans le fichier database.php, des id nécéssaires (si un n'est pas fait, on stoppe en erreur le fichier en cours et programme une nouvelle de mise à jour) Ca permet les mises dans l'ordre voulu et gere les erreurs
   > on re-bloucle si nouvelle mise à jour demandé les mises à jour et  jusqu'a plus de maj ou que des erreurs. (permet de faire dans l'ordre voulu)
  o Il faudrait logger les erreurs dans la table upgrade pour un meilleur suivi

Qu'en penses-tu?

rub a écrit:

o il faudrait pe pouvoir définir un ordre pour faire les updates et bloquer les mises à jour en cas de soucis... au début, j'avais pensé qu'on pouvait utiliser la nouvelle table "upgrade" (champs order par exemple) mais pas cool il faut definir la liste dans la table donc une mise à jour en base avant les update... Par contre, avec un système d'inclusion, on peut faire les deux:

Sinon, c'est vrai qu'il y a deja un tri qui est fait, mais il est fait sur ID qui est une chaine libre, il faudra donc imposer une norme de nommage pour les avoir dans le bon, du style numérique paddés à gauche avec n zéro et impeche les noms libres.
Par contre, il faudrait arreter le boucle en cas de détection d'erreur.


Sinon aussi et de tête, il me semble (mais pas sur) qu'il n'y a pas le test sur les paramétres indiquant qu'on est en mode mise à jour (comme dans upgrade.php)