THELIA Forum

J'ai voulu utiliser une "copie" d'une base au format THELIA 1.2 et comme de nouveaux champs ont été ajoutés dans les tables évidemment ça coince.

cad ?

J'ai fait de nombreux tests, ton plugin est ok ?

Après quelques essais via phpMyAdmin, sous easyPHP 1.8, il faut bien que j'avoue que je suis incapable de transférer le contenu d'un base au format 1.2 vers une base au format Thelia 1.3.
Si j'en crois les messages ci-dessus il y aurait une solution simple! Quelqu'un pourrait-il me la souffler, je ne cafterai pas

Merci d'avance.

Last edited by jhr (15-07-2007 22:21:17)

Pas si simple, car j'avais un catalogue à transférer

J'ai créé une base vide base_T-1-3 puis j'ai installé Thélia 1.3 sur cette base

Compte tenu que mes connaissances en requêtes SQL sont très limitées et que le changelog est incomplet, j'ai donc opéré de la manière suivante en utilisant les outils fournis par phpMyadmin :
- créer une copie nommée base_transfert de la base au format Thelia 1.2
- dans cette base :
    -supprimer la table boutique
    -supprimer le champs boutique des tables cractéristique, contenu, declinaison, dossier, produit, rubrique
    -dans la table client créer le champs siret
    -dans la table produit supprimer le champs quantité et ajouter le champs ecotaxe
    -s'il est nécessaire de transférer les tables citées dans le changelox, modifier les tables comme indiqué
    note : les champs sont a insérer de manière à respecter l'ordre dans lequel ils sont placés dans la base Thelia 1.3
- transférer table par table,les tables dont le contenu a été modifié (rubrique, client, produit, caractéristique ... selon les cas, par exemple, la table pays n'a vraisemblablement besoin d'être transférée). Etant donné la modification de la gestion des images la table image n'a pas été transférée, tout est à refaire.
- sélectionner la base_transfert
- sélectionner une table à transférer et l'afficher (mode afficher ou mode structure)
- exporter : format : SQL, structure : cocher if not exist,type d'exportation: insert, cocher transmettre, executer, enregistrer la requete(noter dossier et nom.sql)
- sélectionner base_T-1-3
- appliquer les requetes sql enregistrées : onglet SQL, emplacement du fichier texte/parcourir puis executer

Quand il n'y a ni oubli ni erreur ça marche au poil

On aurait pu faire plus simple:
- sélectionner la base de donnée base_transfert, exporter, sélectionner les tables à transférer, format SQL, ajouter if not exist, transmettre, executer ...
- sélectionner la base base_T-1-3, SQL etc...

Et si l'on oublie pas de vider le cache le contenu devrait s'afficher

J'ai dû oublier des corrections, des indications ... alors je conseille à ceux qui voudraient utiliser les indications ci-dessus de revoir en détail la structure de leurs bases de données avant d'effectuer des transfert, au besoin, créer des copies des bases de départ et d'arrivée et travailler sur ces copies.

Last edited by jhr (16-07-2007 14:15:15)

Effectivement le changelog.txt est à la racine du site et effectivement il n'explique pas comment créer de nouvelles tables et surtout il n'explique pas quelles tables sont inutiles et quelles tables et quels champs sont à ajouter et à supprimer.
AVANT TOUTE OPERATION SUR UNE BASE DE DONNEE EN LIGNE, LA SAUVEGARDER (et plutôt deux fois qu'une) et essayer de travailler sur des "copies" charger sur son ordinateur.
Pour connaître les modifications à faire sur une base thelia 1.2 il faut comparer les fichiers thelia.sql contenus dans les dossiers install des deux versions et après il faut s'accrocher à phpMyAdmin pour soit adapter la base existante au format thelia 1.3 ou (sans doute plus facile) vider la base existante, installer Thelia 1.3 sur cette base avec création automatique de toutes les tables et champs et ensuite transférer le contenu des tables au format Thelia 1.2 comme je l'ai indiqué ci-dessus. C'est moins délicat que cela paraît car phpMyAdmin/sql fournissent des gardes-foux

J'ai expliqué ci-dessus comment j'ai été contraint de faire, avec succès.

il faut dire que je travaille sur mon ordinateur avec easyPHP et donc sans risque; avec une base installée sur un serveur cela est plus stressant.

Last edited by jhr (16-07-2007 19:27:11)

Ok on est bien d'accord, à ce jour il n'existe pas de procédure de migration de base 1.2.x --> 1.3.0 il faut "bricoler". La meilleure solution (encore une fois à ce jour) reste une install fraiche d'une 1.3.0 et ensuite import des tables nécéssaires depuis une 1.2.x je suppose ?
PhpMyAdmin, je suis pas fan, je suis plus à l'aise en console qu'avec une interface web et quand à faire l'upgrade sur un serveur de prod ... ca sera pas pour tout de suite. Actuellement je travaille sur un serveur de dev, avec backup toutes les heures et la possibilitée de remonter jusqu'à 60 jours, le tout repliqué sur 2 autres serveurs de backup. En avant les boulettes !
Bon merci de ta réponse, je vais attendre un peu de voir s'il y a une procédure propre d'upgrade, avant de me lancer dans une migration un poil plus bricolo.

Merci yoan pour ta confirmation. Donc de mon coté, pas besoin d'attendre une procédure d'upgrade de 1.2.x --> 1.3.0 car il n'y en aura pas c'est bien ca ?
Bon, benh reste plus qu'à prevoir une nuit blanche pour ce week end, je cours acheter un pack de bières !

Ah c'est vrai, t'as raison, PSAI , c'est vrai j'ai utilisé le change log de la 1.2.3(c'était dans la beta 1.3b , une beta,... un peu comme moi) ,
et je n'avais pas vu que dans le changeLog.txt de la 1.3, les créations de table avaient  été supprimées, mais mis à part le problème avec les plugins qui m'a pris un petit moment , c'est vrai que ça ne dure pas des heures.

Last edited by david49 (17-07-2007 10:29:14)

Je fais une upgrade de 1.3b3 vers 1.3 et je trouve des autres modifs dans la base qui n'apparaissent pas dans le message de jhr:

dans la table message, il y a en plus un champ "protege" smallint(6) par rapport à la 1.3b3
dans la table variable, il y a en plus un champ "protege" smallint(6) par rapport à la 1.3b3

Sais pas à quoi y servent pour l'instant !. Autrement, pour venir de la 1.2 j'avais utilisé la même méthode.

On peut aussi supprimer les entrées photorubw et photoprodw de la table variable.

Dans le dossier client/gfx/photos/contenu-dossier-produit-rubrique on peut supprimer les dossiers petite-grande en prenant bien sur soin de conserver les grandes photos et de les replacer au niveau ou étaient les dossiers petite-grande. ceci entraîne bien sur des modifs dans les templates, suppression de #PETITE et #GRANDE.

Voilà ce qui m'a sauté aux yeux en plus des autres choses mentionnées par mes prédécesseurs.

Etrange, car normalement, à la ligne 83 du même fichier est inclus le fichier Variable.class.php où est déclaré la classe Variable ?

Bonjour

Je tiens a préciser que je ne suis pas DeV PHP, j'ai, à chacunes des erreurs, supprimé les lignes concernées et c'est plutôt MIRACULEUX, parce que ça fonctionne.

Je teste sur une debian à distance serveur dédié.

@+

Bonjour,

Je viens juste de procéder à la mise à jour du logiciel.. Effectivement, les congés ont duré mais le magasin où je bosse à fermer et c'était des congés sans solde étant récemment embauché.
Donc, je redémarre sur la version 1.3.1, y intègre ma base de données modifiées et je mets mes templates à la racine du site, là-dessus je déplace mes images comme indiqué ci-dessus et elles ne s'affichent pas malgrès la modif du #petite #grande en #image, l'url affiche "fonctions/redimlive.php?nomorig=../client/gfx/photos/produit/palettes_40.gif&width=159&height=&opacite=&nb=& miroir=".
Si qqn peut m'éclairer.

Cordialement, Aurélien canevat.