Jump to content

Maj 1.9.1.1 Gros Pb Ean

requiem
 Share

Recommended Posts

requiem Rookie

requiem

Posted
Posted (edited)

Bonjour,

 

suite à une mise à jour de 1.6.0.9 vers 1.6.1.1. ( 1 click upgrade )

 

nous avons observé un problème avec les EAN13. ce probleme à eu des répercutions importantes sur les ventes Marketplace.

 

sur plus de 4000 produits , 736 sont devenus erronés à cause de la mise à jour.

 

tous les EAN13 comportant des 0 en tête de chaîne de caractères on été tronqué par la mise à jour. 

 

les ean13 n'étaient donc plus valide suite à la mise à jour.

 

la mise à jour fait une sauvegarde SQL avant (heureusement) . sur lesquelles nous avons bien vérifié la présence des 0 devant les EAN. 

 

ce qui c'est passé. a la mise à jour l'upgrade est allé modifié ces champs en se trompant de TYPE. 

 

on constatera pour preuve l apparition de 0 dans les champs EAN13 de la table XX_product. preuve du passage du type String en entier ( int )

 

ça répond au post suivant qui n'a pas trouvé de réponse 

 

ici

 

il a fallu pas mal de temps pour trouver la cause.

nous espérons avoir un commentaire des équipes de dev. une erreur comme ça c'est assez grave.

 

correction : mise en place d'un script qui va corriger tous les ean ( strlen($p['ean13'] <> 13 )  et ajouter les 00 manquants

 

cdlt

seb

Edited by requiem (see edit history)
Link to comment
Share on other sites
Mediacom87 Grand Master

Mediacom87

Posted
Posted

Voici les lignes concernée dans le fichier 1.6.0.11.sql de l'upgrade

ALTER IGNORE TABLE `PREFIX_product` CHANGE `ean13` `ean13` BIGINT( 15 ) NULL DEFAULT NULL;

ALTER TABLE `PREFIX_product` CHANGE `ean13` `ean13` VARCHAR( 13 ) NULL DEFAULT NULL;

ALTER IGNORE TABLE `PREFIX_product_attribute` CHANGE `ean13` `ean13` BIGINT( 15 ) NULL DEFAULT NULL;

ALTER TABLE `PREFIX_product_attribute` CHANGE `ean13` `ean13` VARCHAR( 13 ) NULL DEFAULT NULL;
Link to comment
Share on other sites
requiem Rookie

requiem

Posted
  • Author
Posted (edited)

Sinon c’est la version 1.6.x.x de PrestaShop et non pas la 1.9.x.x

 

effectivement une petite "dyslexie claviétale"  si je puis me permettre.  surement l'agacement suite à un cet upgrade. 

 

bref merci pour ta réponse. cependant je ne comprends pas la réponse sur la forge. on ne fait pas passer un EAN13 en Big int 15. _ça me dépasse littéralement.  je m'étonne également de ne pas avoir vu plus de retour sur le sujet. ça me donne l'impression que prestashop n'est pas aussi répandu que l'on nous le fait croire. ou que 95 % des sites installés ne sont pas rentable. les réponses ne se bousculent pas non plus sur le Forum. j'ai connu des forums bien plus réactif ou chaque post avait plusieurs réponses constructives. "sur ce forum beaucoup beaucoup de post sans réponses je vois" ( yoda ) .

le faux open source a ses limites. 

il est dangereux à terme de baser un business modèle de grande capacité sur cette plateforme. je ne détaillerais pas pourquoi. mais ce type d'expérience est complètement répréhensible à une agence Web qui ne serait pas assez professionnel , et qui en ne profitant que d'outils open source sans être capable de maîtriser totalement les scripts se risque à une gestion hasardeuse de sociétés sur qui repose le compte d'exploitation. 

l'assistance au Ecommerce n'est pas prêt de s'arrêter.

( avis personnel bien sûr )  

 

bonne journée

Edited by requiem (see edit history)
Link to comment
Share on other sites
Mediacom87 Grand Master

Mediacom87

Posted
Posted

Des précisions concernant cette procédure :

 

 

IGNORE is a MySQL extension to standard SQL. It controls how ALTER TABLE works if there are duplicates on unique keys in the new table or if warnings occur when strict mode is enabled. If IGNORE is not specified, the copy is aborted and rolled back if duplicate-key errors occur. If IGNORE is specified, only one row is used of rows with duplicates on a unique key. The other conflicting rows are deleted. Incorrect values are truncated to the closest matching acceptable value.

As of MySQL 5.7.4, the IGNORE clause for ALTER TABLE is removed and its use produces an error.

Source : http://dev.mysql.com/doc/refman/5.7/en/alter-table.html#alter-ignore-table

Link to comment
Share on other sites
Mediacom87 Grand Master

Mediacom87

Posted
Posted

Bonjour,

 

Un code ean stocké en bigint ? hérésie. Un code ean ne doit pas être considéré comme un nombre ! stocké en nombre le premier 0 saute et du coup les code ean ne sont plus valables

 

Cdt

c'ets juste la mise à jour qui fait cette bétise pas la base, les données ne furent jamais en bigint !

Link to comment
Share on other sites

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 account

Sign in

Already have an account? Sign in here.

Sign In Now
 Share
Go to topic listing
×
×
  • Create New...