mise a jour impossible de 1.6.1.4 vers 1.6.1.6

[docmusicstation]

J ai tenté de faire la mise a jour de mon site vers la 1.6.1.6 (en local ) .....   

ca bloque lors de la creation de l archive de sauvegarde ......

Qui rencontre le meme soucis ?  

[doekia]

Si ça bloque c'est soit que tu as un problème de permission à lire l'un des fichiers, soit que l'un des fichiers est trop volimeux (ancienne archive), soit que le max_execution_time de ton hébergement te fait des siennes.

 

J'ai migré 15 boutiques 1.6.1.4 vers 1.6.1.6 sans problèmes

[docmusicstation]

merci pour votre reponse. 

Cela bloque lors de l'archivage   le dernier message est : docs\csv_import\categories_import.csv  ajouté a l archive ... 

Les droits sont les memes sur les fichiers deja ajoutés et ceux qui ne le sont pas encore . ..

Les fichiers en cause font entre 1 et 3 ko ...

[wizit]

C'est peut être un fichier téléchargé avant qui est trop lourd

Quoi qu'il arrive il faut impérativement faire une sauvegarde manuelle avant :-)

[docmusicstation]

je suis en local ....    

Les fichiers du repertoire sur lequel ca bloque font entre 1 et 18 Ko  

[docmusicstation]

ne trouvant pas de solution pour le moment en mise a jour avec 1 click upgrade

J'ai tenté une mise a jour manuelle en local ....  

 

et la ca bloque sur 

ALTER TABLE `ps_cart_product` CHANGE `id_product_attribute` `id_product_attribute` int(10) unsigned NOT NULL DEFAULT '0'

]]>

[doekia]

ne trouvant pas de solution pour le moment en mise a jour avec 1 click upgrade

J'ai tenté une mise a jour manuelle en local ....  

 

et la ca bloque sur 

ALTER TABLE `ps_cart_product` CHANGE `id_product_attribute` `id_product_attribute` int(10) unsigned NOT NULL DEFAULT '0'

]]>

Bloque? tu veux dire que ça prend longtemps? Ce qui est possible avec une base de données ancienne.

Sinon ce serait bien de donner le message d'erreur

Et aussi de vérifier le log d'erreur du serveur MySQL pour voir si par exemple tu ne serais pas en saturation de l'espace temporaire pour cette opération.

 

PS: Qu'est ce que c'est que ces caractères ]]>

[docmusicstation]

fin du message lorsque je lance localhost/Nom du repertoire/install/upgrade/upgrade.php  apres mise a jour manuelle : 

 

<sqlQuery>

<![CDATA[

ALTER TABLE `ps_cart_product` CHANGE `id_product_attribute` `id_product_attribute` int(10) unsigned NOT NULL DEFAULT '0'

]]>

</sqlQuery>

Voila le message 

et je n ai rien dans les log d erreur !  

Edited June 26, 2016 by docmusicstation (see edit history)

[AGUAGREEN]

Hello Newbie,

Je suis intéressé par votre souci, avez-vous trouvé la réponse/solution ?

Cdmt

[docmusicstation]

Bonjour

Oui j'ai pu trouver la solution: 

La mise a jour s'arretait lors du backup des fichiers. J'ai fait une sauvegarde  via FTP des fichers  et Phpmyadmin pour la BDD.

Ensuite dans le module 1 clickupgrade  dans option de mise a jour  mettre NON a sauvegarde des fichiers    et des images, Validez le changement.

Puis lancez la mise a jour. Pour etre certain j'avais fait la procedure en local avant de la lancer sur le serveur.

[AGUAGREEN]

Merci pour la réponse. Limpide. Si j'ai bien compris, la mise à jour n'a pas aboutie chez vous...

Chez nous, toute la mise à jour a été faite complètement (via la mise à jour en 1 click) hormis ce message qui nous perturbe. Cependant tout semble bien fonctionner...

Relancer une mise à jour équivaudrait à revenir à la version précédente (restaurer rollback) puis recommencer, ce qui serait gênant sachant que de nombreux achats ont eu lieu entretemps et recharger une base sql sans risques...

On a demandé à quelques expert l'incidence que cette erreur pourrait avoir dans le temps => iles premiers sont dubitatifs et ne connaissent pas ce genre d'erreur...

Encore merci, je vous tiendrai au courant.

[docmusicstation]

Re

 

Si la mise a jour a abouti a partir du moment ou j ai enlever les options de sauvegarde dans le module  click upgrade

[Emmanuel D]

J'ai eu la même erreur entre 1.6.1.5 et 1.6.1.6 mais à priori pas d'impact :

 

SQL 1.6.1.6 1142 in ALTER TABLE `ps_cart_product` CHANGE `id_product_attribute` `id_product_attribute` int(10) unsigned NOT NULL DEFAULT '0': ALTER command denied to user 'xxxxxxx'@'10.0.xxx.xxx' for table 'ps_cart_product'

Erreur(s) détectée(s) pendant la mise à jour.

 

Je suis allé voir la structure de la table : "ps_cart_product" et pour "id_product_attribute`, les propriétés sont déjà bien à int(10), NOT NULL et Default à 0 !

 

5 id_product_attribute int(10)   UNSIGNED Non 0

 

Donc je ne sais pas ce que devait changer cette commande SQL mais à priori, il n'y avait sans doute rien à faire vue que la structure à l'air déjà correcte.

 

Emmanuel.

[doekia]

J'ai eu la même erreur entre 1.6.1.5 et 1.6.1.6 mais à priori pas d'impact :

 

SQL 1.6.1.6 1142 in ALTER TABLE `ps_cart_product` CHANGE `id_product_attribute` `id_product_attribute` int(10) unsigned NOT NULL DEFAULT '0': ALTER command denied to user 'xxxxxxx'@'10.0.xxx.xxx' for table 'ps_cart_product'

Erreur(s) détectée(s) pendant la mise à jour.

 

Je suis allé voir la structure de la table : "ps_cart_product" et pour "id_product_attribute`, les propriétés sont déjà bien à int(10), NOT NULL et Default à 0 !

 

5 id_product_attribute int(10)   UNSIGNED Non 0

 

Donc je ne sais pas ce que devait changer cette commande SQL mais à priori, il n'y avait sans doute rien à faire vue que la structure à l'air déjà correcte.

 

Emmanuel.

 

En effet tu avais tout bien fait et je n'avais pas correctement regardé ton message d'erreur Le truc qui m'avais trompé est qu'il n'y a pas de mise à jour de structure de la table ps_cart_product dans le github, donc impossible de savoir la cause de ce patch, la colonne étant en int(10) NULL depuis la 1.5.0.12.

 

Seule la branche tag 1.6.1.6 contient ce patch marqué d'ailleurs complètement à l'opposé de ce que fait le code:

julienbourdeau [+] IN: All key must not be nullable

 

La structure de cette colonne change bizarrement

1.5.1.0 `id_product_attribute` int(10) unsigned DEFAULT NULL,

          .

          .

          .

1.6.1.5 `id_product_attribute` int(10) unsigned DEFAULT '0',

1.6.1.6 `id_product_attribute` int(10) unsigned NOT NULL DEFAULT '0'

CREATE TABLE `PREFIX_cart_product` (
  `id_cart` int(10) unsigned NOT NULL,
  `id_product` int(10) unsigned NOT NULL,
  `id_address_delivery` int(10) UNSIGNED DEFAULT '0',
  `id_shop` int(10) unsigned NOT NULL DEFAULT '1',
  `id_product_attribute` int(10) unsigned NOT NULL DEFAULT '0',
  `quantity` int(10) unsigned NOT NULL DEFAULT '0',
  `date_add` datetime NOT NULL,
  PRIMARY KEY (`id_cart`,`id_product`,`id_product_attribute`,`id_address_delivery`),
  KEY `id_product_attribute` (`id_product_attribute`),
  KEY `id_cart_order` (`id_cart`, `date_add`, `id_product`, `id_product_attribute`)
) ENGINE=ENGINE_TYPE DEFAULT CHARSET=utf8 COLLATION;

Et le commentaire du commit à une signification un peu obscure, d'ailleurs QUID de la colonne id_address_delivery et de ce commentaire

 

Et pour finir ta structure est en effet conforme, ceci est dû au fait que personne n'a compulsé la documentation:

http://dev.mysql.com/doc/refman/5.7/en/data-type-defaults.html

 

If the column cannot take NULL as the value, MySQL defines the column with no explicit DEFAULT clause. Exception: If the column is defined as part of a PRIMARY KEY but not explicitly as NOT NULL, MySQL creates it as a NOT NULL column (because PRIMARY KEY columns must be NOT NULL). Before MySQL 5.7.3, the column is also assigned a DEFAULT clause using the implicit default value. To prevent this, include an explicit NOT NULL in the definition of any PRIMARY KEY column.

Donc le construction de la table étant initialement erronée, Le moteur MySQL avait de lui même corrigé la structure.

 

D'ailleurs il suffit de faire le dump de ta table actuelle pour le vérifier:

CREATE TABLE `ps_cart_product` (
  `id_cart` int(10) unsigned NOT NULL,
  `id_product` int(10) unsigned NOT NULL,
  `id_address_delivery` int(10) unsigned NOT NULL DEFAULT '0',
  `id_shop` int(10) unsigned NOT NULL DEFAULT '1',
  `id_product_attribute` int(10) unsigned NOT NULL DEFAULT '0',
  `quantity` int(10) unsigned NOT NULL DEFAULT '0',
  `date_add` datetime NOT NULL,
  PRIMARY KEY (`id_cart`,`id_product`,`id_product_attribute`,`id_address_delivery`),
  KEY `id_product_attribute` (`id_product_attribute`),
  KEY `id_cart_order` (`id_cart`,`date_add`,`id_product`,`id_product_attribute`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8;

Comme tu le constates la colonne id_adress_delivery a été silencieusement corrigé par rapport à la définition et contient bien la directive NOT NULL, l'objet d'un probable prochain patch totalement inutile qui aura aussi le bon goût de générer une fausse erreur à la mise à jour.