Piwigo.org

VDigital · 2005-12-14 22:46:52

Il faut que les upgrades passent :

- soit par une demande de confirmation:
Veuillez confirmer que vous passer de la version 1.5.0 à la 1.5.1 en donnant le code 1.5.0, ci-après : _._._

- soit par un contrôle d'une ligne d'une table (table config) qui contiendrait le MD5(nomdelabaseMySQL et Version antérieure de PWG), seuls les install.php et upgrade.php modifiraient cette ligne.

Cf. le topic de Jacques Upgrade 140 to 151 qui m'a donné trop de mal à résoudre à distance.

Faites votre choix? Ou plus simple...

z0rglub aura le dernier mot cela va de "soit". 8-)

Quand vous vous serez décidés, je veux bien faire la demande d'amélioration là où je dois la faire.

Dernière modification par VDigital (2005-12-14 22:48:59)

volcom · 2005-12-16 09:37:38

excuse moi mais je n'ai pas saisi le problème :|

chrisaga · 2005-12-16 13:46:11

Je pense que l'on pourrait stocker la version courante de PWG et tester cette version dans la procédure d'upgrade au lieu de demander au webmaster de choisir lui-même.
Rien n'empêche de conserver un accès plus ou moins direct aux procédures d'upgrade sans passer par la détection pour traiter les cas particuliers.

On aurait une procédure d'upgrade plus simple et plus sure.

VDigital · 2005-12-16 19:04:49

volcom a écrit:
excuse moi mais je n'ai pas saisi le problème :|

Jacques était en 1.4.0 mais il a malencontreusement cliqué sur la migration depuis la 1.5.0.
Résultat:
Les modifs de structure et de contenu des tables entre 1.4.0 et 1.5.0 n'ont pas été appliquées.
Il s'est retrouvé avec des tables "bancales" comme des moutons à cinq pattes.

En positionant un champ que la migration pourrait tester, on pourrait éviter le problème.
L'inconvénient est que ce champ n'existe pas en 1.3, ni 1.4, ni même en 1.5, ce principe ne serait applicable qu'à partir d'une 1.5.2, voire 1.6 pour une migration 1.6.1 et au delà.
Dans tous les cas une migration de 1.5.1 vers 1.6.2 serait dans l'incapacité de testé un tel champ et ne pourrait vérifier que l'on part bien d'une 1.5.1.
Moralité: Bien que l'avis de Chris est justifié, je pense qu'il faut au plus vite introduire le champ mais qu'on est dans un premier temps obligés quelque peu d'utiliser la demande de confirmation.

VDigital · 2005-12-16 19:12:58

chrisaga a écrit:
Rien n'empêche de conserver un accès plus ou moins direct aux procédures d'upgrade sans passer par la détection pour traiter les cas particuliers.

Oui tout à fait d'accord... Un paramètre "Bypass check version" en quelque sorte.
C'est indispensable pour de bidouilleurs (comme nous et peut être d'autres) mais attention à la sécurité.
Quand "Bypass" est activé, upgrade ne devrait il pas être lancé avec un parm style 6 caractères (préalablement stockés run précédent qui enverrai un mail avec le lien+parm à l'adresse du webmaster).
6 premiers caractères d'un MD5(du current time) stockés dans la table config lors du run de upgrade sans le parm.
C'est un peu compliqué certes, mais Bypass est un peu dangeureux quand même.

plg · 2005-12-16 22:16:44

(mais pourquoi ce topic est il privé ?)

chrisaga · 2005-12-19 21:13:44

z0rglub a écrit:
(mais pourquoi ce topic est il privé ?)

Je ne sais pas ;-)

VDigital · 2005-12-19 23:37:54

z0rglub a écrit:
(mais pourquoi ce topic est il privé ?)

Si tu veux le déplacer en discussion, pas de problème.
Je ne suis pas modérateur de la partie du forum où se trouve actuellement ce topic.
Merci aussi de retirer ton post et le mien si tu décides de le dépacer...

flipflip · 2005-12-20 14:32:24

Je vais peut être dire une connerie... Enfin surtout j'ai rien pour le vérifier, mais la version est bien visible dans la page d'accueil de l'admin, donc soit elle est stocké en base, soit dans un fichier, soit en dur de la page. Dans les deux derniers cas il doit être possible de la récupérer ?

rub · 2005-12-20 23:33:12

Pour moi, je pense qu'il ne faut plus proposer des fichiers upgrade.version.php mais un fichier appelant unique.

La notion de version ne doit pas être importante ni significative mais uniquement à titre d'info.
Je m'explique... si des modifications ont été faites test, mod béta, correction manuelles, il faut que le upgrade gére tout (que le site soit en version 1.1.0 ou 1.5.0.beta, ect...)

Pour ca, il y a déjà eu une discussion sur le forum cf. ce topic
Et l'idée serait :
o de "lister" toutes les upgrades pour passer d'une version à une autre (le passage d'une version 1.x.0 à 1.y.0 pouvant comporter plusieurs upgrade)
o de les passer si nécessaire (une fois seulement ou 0 si installation)
o et dans le "bon" ordre...

Avec ca, ca devrait couvrir un grand nombre des soucis d'install, faciliter les patch, et les mises à jours des versions intermédiaires béta et de test.

Non?

VDigital · 2005-12-21 07:15:42

Tu as très certainement raison, faire une "usine à gaz" pour l'installation ne semble ne pas être dénué de bon sens.

Un Upgrade gère toutes les situations : why not ?
- y compris le coup d'un jeu de tables incomplet?
- y compris des tables corrompues?
- y compris des tables "altérées" formats de colonne différents?
- y compris les colonnes ajoutées aux tables existantes?
- y compris des tables "étrangères" avec des clés étrangères?
- sans parler de la modification des données comme dans la table config...

Tu as raison rub. Moi, je ne sais pas comment on peut faire.

Cependant on peut se permettre de le faire car l'upgrade ne devrait tourner qu'une fois.
Malgré tout, il ne faut pas qu'il plante car sinon cela deviendrait alors encore plus complexe.
Pour ne pas qu'il se plante, ne doit-il pas rester simple?
Je ne sais pas.
Je sais que pour simplifier le support il nous faut une procédure d'upgrade en béton.
Mais béton de chez...
Quant aux bétas et BSF intermédiaires: Non! d'avance, pas d'upgrade.

8-)

rub · 2005-12-22 23:10:05

VDigital a écrit:
Un Upgrade gère toutes les situations : why not ?
- y compris le coup d'un jeu de tables incomplet?
- y compris des tables corrompues?
- y compris des tables "altérées" formats de colonne différents?
- y compris les colonnes ajoutées aux tables existantes?
- y compris des tables "étrangères" avec des clés étrangères?
- sans parler de la modification des données comme dans la table config...

Je dis oui, oui, oui..

VDigital a écrit:
Pour ne pas qu'il se plante, ne doit-il pas rester simple?

Justement la solution proposée dans le topic permet de gérer les problèmes car c'est des enchainements d'élements simples .
C'est centraliser, tout en étant parfaitement modifiable.

VDigital a écrit:
Je sais que pour simplifier le support il nous faut une procédure d'upgrade en béton.
Mais béton de chez...

Ca oui...

VDigital a écrit:
Quant aux bétas et BSF intermédiaires: Non! d'avance, pas d'upgrade.
)

Pas d'upgrade pour les béta et BSF, à moitié d'accord...
C'est pas simple à faire pour une BSF car on le prend dans la globalité mais c'est pas compliqué avec l'idée du topic et en plus nécessaire à faire un jour ou l'autre.. ALors autant le faire au plus tot...

Le fichier update qui va bien pourra être un livraison à faire avec les modifs!

Je m'explique, il y a fichier global d'update (cf topic ).
Pour chaque évolution, le developper livre:
o ses sources
o une fichier d'upgrade pour sa partie (ui sera vérifié par plusieurs membres de l'équipe)

Ca permet de faire les upgrade de tout (béta, bsf, ect...), il restera simplement à l'intégrateur de mettre les fichiers upgrade ajouté comme étant utilisé par défaut dans l'installation. (D'ailleurs, lors de l'installation, il suffit que mettre tous les update livré en utilisé).

Piwigo.org

Annonce

#1 2005-12-14 22:46:52

[Migrations]

#2 2005-12-16 09:37:38

Re: [Migrations]

#3 2005-12-16 13:46:11

Re: [Migrations]

#4 2005-12-16 19:04:49

Re: [Migrations]

volcom a écrit:

#5 2005-12-16 19:12:58

Re: [Migrations]

chrisaga a écrit:

#6 2005-12-16 22:16:44

Re: [Migrations]

#7 2005-12-19 21:13:44

Re: [Migrations]

z0rglub a écrit:

#8 2005-12-19 23:37:54

Re: [Migrations]

z0rglub a écrit:

#9 2005-12-20 14:32:24

Re: [Migrations]

#10 2005-12-20 23:33:12

Re: [Migrations]

#11 2005-12-21 07:15:42

Re: [Migrations]

#12 2005-12-22 23:10:05

Re: [Migrations]

VDigital a écrit:

VDigital a écrit:

VDigital a écrit:

VDigital a écrit:

Pied de page des forums