Re: [Dolibarr-dev] Module d'import Magento->Dolibarr

[anthony . poiret]

Bonjour,

Je reviens sur ce thread pour faire un petit point.

Quand je demandais comment forcer la mise à jour, je parlais de  
l'application du script de migration d'une version à la suivante. Je  
n'ai en effet posté que le patch pour la version 3.0 de Dolibarr, mais  
j'en ai préparé un second pour la 2.9 afin de permettre l'utilisation  
du module d'import.

Si j'ai bien compris, le script de migration devrait donc être forcé  
puisque l'appli ne sera pas en phase avec la version du script (2.9 ->  
3.0) si l'installation est faite sur une version 2.9, je me trompe?

Autre chose, en augmentant la volumétrie de données lors des tests,  
j'ai constaté quelque problème dans deux autre modules et un besoin  
dans un troisième: commande, produit et contact (en version 3.1 alpha).

Pour commande, le problème est dans le fetch: à la fin de celui-ci, on  
appelle $this->fetch_lines(), fonction dont le code m'a quelque peu  
étonné:
> while ($i < $num)
> {
> $objp = $this->db->fetch_object($result);
> $line = new OrderLine($this->db);
> $line->rowid            = $objp->rowid;
> ...
> $line->fk_parent_line        = $objp->fk_parent_line;
>
> $this->ref          = $objp->product_ref; // TODO deprecated
> $this->product_ref  = $objp->product_ref;
> ...
> }

$this étant ici la commande (à laquelle je comprend très bien qu'on  
assigne les lignes). Cependant, la ligne $this->ref [...] // TODO  
deprecated pose un réel problème, d'un part parce qu'on est dans un  
while, je ne vois donc pas l'utilité d'affecter des attributs d'une  
commande composée de multiples lignes, d'autre part parce que la ref  
de la commande n'est pas censé être celle du dernier produit de ses  
lignes (cette manip' purge tout simplement la première référence de  
commande updaté pour un type donné si la dernière ligne est un frais  
de port, et cause ensuite une erreur sql, la ref de la commande  
faisant partie avec le type d'une contrainte unique). J'ai pour ma  
part passé cette ligne en commentaire afin de supprimer le bug,  
cependant les autres assignations à $this me parraissent douteuses  
dans ce contexte.

Pour produit, il s'agit d'un simple besoin lié au module en cours de  
maintenance, puisque Magento définit ses ref produit sur 64 caractères  
et Dolibarr sur 32. Je pense qu'il serait possible d'augmenter cette  
taille afin de faciliter les synchronisation eCommerce de manière  
générale, je l'ai pour ma part passé à 255 afin d'avoir de la marge  
(je ne pense pas que cela nuise dramatiquement aux performances, mais  
j'attend une confirmation).

Enfin, pour les contacts, il ne s'agit pas vraiment d'un problème mais  
encore une fois d'un besoin lié à l'import. Magento ayant un  
fonctionnement particulièrement différent de Dolibarr pour l'adressage  
des commandes, chaque adresse est considérée comme unique alors que  
Dolibarr les regroupe en contact. Je compte ajouter une fonction me  
permettant d'effectuer un select dans le DAO de contact, afin de ne  
pas générer un contact par commande pour une société donnée (sachant  
que ces contacts ont généralement les mêmes noms, adresse, téléphone  
et fax). Je ne pense pas que cela pose de problèmes, mais j'attend  
encore une fois confirmation avant de présenter le patch.


Dernière chose, je n'ai pas encore eu le temps de vérifier les  
implication sur version 2.9 ni 3.0, par conséquent, je m'en tiens pour  
l'instant à la 3.1 alpha.

Cordialement,

Anthony Poiret



"Laurent Destailleur (eldy)" <address@hidden> a écrit :

> La migration est deja forcé quand l'appli est en version non en   
> phase avec les scripts.
>
> Forces des modifs en 3.1 sur une version 2.9 n'est pas possible   
> puisque quand la 2.9 est diffusé les script de la 3.1 n'existait pas  
>  et donc on ne peut pas forcer des script n'existant pas.
>
> Mais un module peut forcer ses propres commandes sql en mettant les
> ordres dans data.sql
>
> Voir
> http://wiki.dolibarr.org/index.php/D%C3%A9veloppement_module#Cr.C3.A9er_vos_tables_SQL_et_la_classe_PHP_des_accesseurs_.28optionnel.29
>
> Toutefois, un module n'est pas sensé touché à la structure interne   
> de dolibarr sous peinde de rendre l'appli inutilisable ou impossible  
>  à migrer avec la prochaines version.
>
>
> Le 30/05/2011 17:11, address@hidden a écrit :
> > Bonjour à tous,
> >
> > Je viens de terminer une tâche que m'a confié Cyrille concernant la  
> >  mise à jour et l'amélioration du module d'import  
> > Magento->Dolibarr.  Il importe désormais les catégories magento et  
> > affecte  automatiquement les produit importés dans celui-ci; mon  
> > problème  est qu'il requiert le patch catégories que j'ai posté  
> > dans un autre  thread (corrigeant le problème des doublons de  
> > labels impossible  pour des mères différentes).
> >
> > Or ce patch comprend des scripts d'altération SQL. Si je ne me   
> > trompe pas, ceux-ci sont appliqués à la mise à jour de Dolibarr.
> >
> > Y'a-t-il un moyen de forcer l'application du script sans avoir   
> > besoin de mettre l'application à jour (bien sûre, sans passer par   
> > la console phpMyAdmin), le but étant de proposer un package pour ce  
> >  module appliquant les altérations SQL et extrayant le module pour   
> > les versions 2.9 et 3.0 (partant du principe que le patch catégorie  
> >  sera intégré pour la 3.1, en attendant confirmation)?
> >
> > J'ai peut-être mal cherché dans la doc, cependant je serai ravi de   
> > disposer d'un éclaircissement à ce sujet.
> >
> > Merci d'avance,
> >
> > --------Translation----------
> > Hello everyone,
> >
> > I just finished a task entrusted to me by Cyril on updating and   
> > improving the import module Magento-> Dolibarr. It is now important  
> >  magento categories' and automatically assigns the product imported  
> >  into it, my problem is that it requires the patch categories that  
> > I  posted in another thread (correcting the impossibility of   
> > duplicating labels to different mothers) .
> >
> > Now this patch includes SQL scripts alteration. If I'm not   
> > mistaken, they are applied at Dolibarr update.
> >
> > Is there a way to force the implementation of the script without   
> > needing to update the application (although safe, without going   
> > through the phpMyAdmin console), the aim being to offer a package   
> > for this module using the alterations and extracting the SQL module  
> >  for versions 2.9 and 3.0 (assuming that the patch will be   
> > integrated for class 3.1, pending confirmation)?
> >
> > Maybe I missearched in the doc, but I will be glad to have a   
> > clarification on this.
> >
> > Thank you in advance
> >
> > Anthony Poiret
> >
> > _______________________________________________
> > Dolibarr-dev mailing list
> > address@hidden
> > https://lists.nongnu.org/mailman/listinfo/dolibarr-dev
>
>
> --
> Eldy (Laurent Destailleur).
> ---------------------------------------------------------------
> EMail: address@hidden
> Web: http://www.destailleur.fr
>
> Dolibarr (Project leader): http://www.dolibarr.org
> To make a donation for Dolibarr project via Paypal: address@hidden
> AWStats (Author) : http://awstats.sourceforge.net
> To make a donation for AWStats project via Paypal: address@hidden
> AWBot (Author) : http://awbot.sourceforge.net
> CVSChangeLogBuilder (Author) : http://cvschangelogb.sourceforge.net
>
>
> _______________________________________________
> Dolibarr-dev mailing list
> address@hidden
> https://lists.nongnu.org/mailman/listinfo/dolibarr-dev