doekia Posted March 17, 2014 Share Posted March 17, 2014 Tout est dans le titre. http://forge.prestashop.com/browse/PSCSX-1149 La requête sous-jacente a la configuration tente d'accéder a des colonnes qui n'apparaissent qu'en 1.5.0.10 + Link to comment Share on other sites More sharing options...
Gregory Roussac Posted March 18, 2014 Share Posted March 18, 2014 Bonjour, Votre mise à jour manuelle n'a pas réussi. L'erreur que vous donnez vient probablement du BO 1.5.6 et dit que la table configuration n'est pas à jour, ajout qui a été fait en 1.5.0.10 effectivement. La mise à jour manuelle est dépréciée (http://doc.prestashop.com/display/PS15/Manual+update), vous devriez plutôt utiliser le module de mise à jour à la place. Cordialement Link to comment Share on other sites More sharing options...
doekia Posted March 18, 2014 Author Share Posted March 18, 2014 Je trouve cela ridicule de se priver de cette fonctionnalité La mise a jour CLI était un grande avancée pour les sites de grosse taille et ayant de la bouteille (montée depuis des versions ancienne). Je voudrais bien voir 1 clic upgrade tenter la mise à jour d'une 1.3.7 ayant 4 ans d'existence D'ailleurs entre parenthèse, j'ai migré avec le CLI (en 2 étapes 1.4 vers 1.5 puis 1.5 vers 1.6) justement parce que le 1clic c'était planté ... ce qui donne une boutique vierge au passage comme souvent lorsque ce dernier se plante. J'ai 4/5 clients avec des grosses shop (80K produits l'un) et le revirement va sûrement changer nos perspectives. PS: Je sais parfaitement d'où vient l'erreur de migration. J'en ai fait l'analyse dans le bug report c'est juste que les scripts sql en dessous de la 1.5.5 ne sont pas appliqués (conformément a un autre choix parfaitement incompréhensible) Link to comment Share on other sites More sharing options...
Gregory Roussac Posted March 18, 2014 Share Posted March 18, 2014 Re, On va regarder ce que l'on peut faire, si c'est possible on va intégrer ce commit. Cette classe est très sollicitée, donc c'est un peu touchy. Merci. Cordialement Link to comment Share on other sites More sharing options...
doekia Posted March 18, 2014 Author Share Posted March 18, 2014 (edited) La classe ?? Je ne pense pas que le problème soit a traiter comme cela Appliquer les patch sql dans le bon ordre jusqu'a atteindre la version souhaitée... dans les grandes lignes. Le problème ne vient pas de la classe ... il vient du mécanisme mis en oeuvre dans l'upgrade Par ailleurs concernant la classe DbPDO... pas sûr que le code qui fasse un return $result->fetch(PDO::FETCH_ASSOC); sur un $return ayant pour valeur null soit une super idée... Edited March 18, 2014 by doekia (see edit history) Link to comment Share on other sites More sharing options...
Gregory Roussac Posted March 19, 2014 Share Posted March 19, 2014 Bonjour, Les patchs sql dans l'ordre ? Si le problème n'est pas sur Configuration::LoadConfiguration() pour les versions inférieures à 1.5.0.10 alors je n'ai pas compris le problème. On va tout simplement retirer ce Configuration::LoadConfiguration() du fichier install/upgrade/upgrade.php. Je ne comprends pas votre remarque sur l’ordre des "patchs" désolé. Mais si vous avez une autre solution sur cette mise en œuvre vous pouvez proposer votre code sur notre repo github. Pour la seconde remarque, j'ai fait un commit mais je ne comprends pas ou vous avez un null dans $result dans la 1.6, à partir de quel fichier avez vous eu cela ? Une autre personne m'avait fait la remarque ce matin pour update_web_browser.php d'une 1.4 donc j'ai reporté sur les fichiers PDO et MySQLi coté module et coté cœur merci. Cordialement Link to comment Share on other sites More sharing options...
doekia Posted March 20, 2014 Author Share Posted March 20, 2014 (edited) Concernant la seconde remarque Je suis a chaque fois perdu avec l'impression que les bugs reports ne sont pas lu. Dans le ticket http://forge.prestashop.com/browse/PSCSX-1149 j'ai reporté l'erreur qui survient en ligne 101 de classes/db/DbPDO.php Ceci survient car la requête que le core tente d'exécuter est en erreur SQL puisque la colonne n'existe pas ... Le code oublie de tester le retour en cas null (l'erreur) et appelle la fonction nextRow() Celle ci return $result->fetch <<!! ICI result est null => fatal Ceci n'affecte pas seulement le bug reporté (ma remarque) Cette erreur n'est pas catchable. On doit tester $result et trow une exception si cela survient ---- Concernant les patch dans l'ordre My bad j'ai associé bêtement 2 infos contradictoires, j'en été arrivé a croire que les patch 1.5.x.x.sql n'étaient pas appliqués alors que l'erreur survient avant le traitement d'aucun d'entre eux. En effet extraire Configuration::loadConfiguration() au debut de upgrade.php pourrait solutionner le problème qui hélas surface quelques lignes plus tard puisque tout Configuration::get appelle loadConfiguration si le hash est vide. Il me semble que la solution serait une classe Configuration directement dans l'install. Une autre approche est de créer les 2 colonnes avec le loadConfiguration dans le cas d'une version de départ < 1.5.0.10. Ce n'est pas très beau car génère des erreurs dans le traitement des patch mais ... ça marche et permet un upgrade CLI ---- Je me demande d'ailleurs comment procède l'autoupgrade ... ne pouvons nous pas utiliser le même dispositif? Edited March 20, 2014 by doekia (see edit history) Link to comment Share on other sites More sharing options...
Gregory Roussac Posted March 20, 2014 Share Posted March 20, 2014 Bonjour, Désolé mais je ne comprends pas votre premier point. Désolé mais je lis les bugs reports. Vous n'y pas evoqué pas la classe PDO. Je ne trouve pas de requête core qui renvoi null dans $result en 1.5 ou 1.6. je ne vois pas comment le ticket PSCSX-1149 concerne le second point évoqué plus haut. Le loadConfiguration a en tout cas été retiré dans https://github.com/PrestaShop/PrestaShop/commit/0ba0651b892331abeb33e3170e533d445db44d0e. Merci. Cordialement Link to comment Share on other sites More sharing options...
Gregory Roussac Posted March 20, 2014 Share Posted March 20, 2014 Cette erreur n'est pas catchable. On doit tester $result et trow une exception si cela survient Si on veut lever un exception en PHP il faut justement qu'elle soit catchable non ? Désolé je ne comprends pas votre remarque. Cordialement Link to comment Share on other sites More sharing options...
doekia Posted March 20, 2014 Author Share Posted March 20, 2014 Heu la 3eme ligne du rapport donne l'erreur produite: {code} while running php -q install/upgrade/upgrade.php,process dies prematurly with:PHP Fatal error: Call to a member function fetch() on a non-object in /var/www/clients/client8/web34/web/classes/db/DbPDO.php on line 101 {code} Je comprend que tu en lises des tonnes mais là désolé je parle bien de la classe DbPDO.php La requête core qui est à l'intérieur du Configuration::loadCategory provoque l'erreur SQL: {code} SELECT c.`name`, cl.`id_lang`, IF(cl.`id_lang` IS NULL, c.`value`, cl.`value`) AS value, c.id_shop_group, c.id_shopFROM `ps_configuration` cLEFT JOIN `ps_configuration_lang` cl ON (c.`id_configuration` = cl.`id_configuration`) {code} id_shop et id_shop_group colonnes inexistantes La ligne 101 assume (indirectement voir 100) que $this->result sera toujours non null. En cas d'erreur SQL ce n'est pas le cas d'où le crash avec le FATAL FATAL a moins d'implementer un error handler set_error_handler() provoque un die() prématuré du code. -- Pour revenir au correctif proposé ... je vais le tester ce jour mais je suis confiant qu'il va solutionner le PSCSX-1149 Cordialement, Link to comment Share on other sites More sharing options...
Recommended Posts
Create an account or sign in to comment
You need to be a member in order to leave a comment
Create an account
Sign up for a new account in our community. It's easy!
Register a new accountSign in
Already have an account? Sign in here.
Sign In Now