[prestashop 1.6] Changer le type d'une clé primaire

[taka10]

Bonjour,

 

Je suis en train de récupérer les adresses d'un client (d'une autre base de données). Les id_adresses actuelles sont composées de 12 chiffres or l'id_adress prestashop est de type int(10),j 'ai donc changé le type directement en bdd pour mettre bigint(12) et j'ai importé les adresses. 

 

Jusqu'ici aucun soucis. Je regarde dans mon backend, j'ai bien la liste des adresses qui remontent, si je regarde sur le détail d'une adresse, tous les champs sont vides.

 

Avez vous une idée d'où cela peut venir ?

 

Merci d'avance 

Jimmy

[Chamie]

Incompatibilité au niveau des structures respectives des tables adresses ?

 

Librement,

 

Chamie

[taka10]

Je ne comprend pas votre réponse, on ne peut pas changer le type des tables, ça me semble étonnant...

 

Merci D'avance

[Chamie]

Avez vous une idée d'où cela peut venir ?

 

Pour vous répondre, je pense que les deux tables, ne sont pas compatible au niveau de leurs structures.

 

Afin de nous en assurer, copier ici la structure des deux tables nous pourrons ainsi les comparer, et voir là où ça bloque.

 

Librement,

 

Chamie

[taka10]

Voici la structure de la table address (vous voulais la structure de la 2ème table mais laquelle ?) :
 

CREATE TABLE IF NOT EXISTS `testps2_address` (
  `id_address` bigint(12) unsigned NOT NULL,
  `id_country` int(10) unsigned NOT NULL,
  `id_state` int(10) unsigned DEFAULT NULL,
  `id_customer` int(10) unsigned NOT NULL DEFAULT '0',
  `id_manufacturer` int(10) unsigned NOT NULL DEFAULT '0',
  `id_supplier` int(10) unsigned NOT NULL DEFAULT '0',
  `id_warehouse` int(10) unsigned NOT NULL DEFAULT '0',
  `alias` varchar(32) NOT NULL,
  `company` varchar(64) DEFAULT NULL,
  `lastname` varchar(32) NOT NULL,
  `firstname` varchar(32) NOT NULL,
  `address1` varchar(128) NOT NULL,
  `address2` varchar(128) DEFAULT NULL,
  `postcode` varchar(12) DEFAULT NULL,
  `city` varchar(64) NOT NULL,
  `other` text,
  `phone` varchar(32) DEFAULT NULL,
  `phone_mobile` varchar(32) DEFAULT NULL,
  `vat_number` varchar(32) DEFAULT NULL,
  `dni` varchar(16) DEFAULT NULL,
  `date_add` datetime NOT NULL,
  `date_upd` datetime NOT NULL,
  `active` tinyint(1) unsigned NOT NULL DEFAULT '1',
  `deleted` tinyint(1) unsigned NOT NULL DEFAULT '0'
) ENGINE=InnoDB DEFAULT CHARSET=utf8;
 
ALTER TABLE `testps2_address`
 ADD PRIMARY KEY (`id_address`), ADD KEY `address_customer` (`id_customer`), ADD KEY `id_country` (`id_country`), ADD KEY `id_state` (`id_state`), ADD KEY `id_manufacturer` (`id_manufacturer`), ADD KEY `id_supplier` (`id_supplier`), ADD KEY `id_warehouse` (`id_warehouse`);

[Chamie]

Je suis en train de récupérer les adresses d'un client (d'une autre base de données). 

 

Celle là ? Tu récupère des adresses que tu souhaite intégrer dans ton prestashop 1.6 si j'ai bien compris. Mais les adresses viennent d'où ? D'un autre prestashop, d'un wordpress ? D'un site quelconque en PHP ?

 

La structure de table que tu as posté est celle de prestashop 1.6, il nous manque donc l'autre.

 

Librement,

 

Chamie

[Whoami]

Bonjour, 

 

La modification int(10) -> bigint(12) a été apportée sur toutes les tables qui ont "id_address" en (fausse) foreign key ? 

Je pense par exemple à ps_orders (avec id_address_delivery, etc...) ou des modules qui pourraient en avoir besoin.

 

Par ailleurs, il est possible aussi qu'il faille l'apporter dans le coeur même du Prestashop (au niveau de l'ORM, des "Validates", etc...).

 

Dans tous les cas, c'est une piste de recherche et non une solution, surtout pour prévenir que les effets de bord risquent d'être importants.

[seb776]

Hello,

 

Mauvaise idée que de changer la structure d'une colonne native de prestashop.

J'en ai fait l'expérience, cela entraîne des problèmes au niveau de la validation, les autres modules et parties qui référence cet id, doivent donc aussi être modifié, idem pour les modules a installer dans le future.

Et que va t-il se passer si la structure change dans une future version de Prestashop ? l'outils de mise a jour va planter ?

 

Bref : très mauvaise idée !

 

Tu dois opérer une transformation sur cet identifiant pour qu'il soit gérable nativement par prestashop. Rien ne t'empêche d'un autre coté d'ajouter une colonne (un champs) à a ta table pour y stocker la valeur originale.

ça peut paraitre plus de taf, mais sur le long terme, c'est ce qu'il faut faire.

 

J'ai fait cette même erreur en pensant gagner du temps, c'est faux, mieux vaut faire comme j'ai dit.

 

Bon courage !

[Whoami]

Totalement d'accord Seb, totalement

 

Ne touche pas au coeur, ton Prestashop te remerciera plus tard.

Avec une modification comme celle-ci, tu es quasiment coincé sur cette version et tu fermes de très nombreuses portes évolutives/modulaires.

 

D'ailleurs, tu importes des bigint en 12, mais sérieusement... il y a plusieurs centaines de millions d'addresses dans ta base de départ ? Oo

 

Tu n'aurais pas plutôt une solution pour "convertir algorithmiquement" les bigint(12) de départ en int(10) avant l'import ? (le mieux étant même de les passer sur moins de caractères).