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)" <[email protected]> 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, [email protected] 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
[email protected]
https://lists.nongnu.org/mailman/listinfo/dolibarr-dev
--
Eldy (Laurent Destailleur).
---------------------------------------------------------------
EMail: [email protected]
Web: http://www.destailleur.fr
Dolibarr (Project leader): http://www.dolibarr.org
To make a donation for Dolibarr project via Paypal: [email protected]
AWStats (Author) : http://awstats.sourceforge.net
To make a donation for AWStats project via Paypal: [email protected]
AWBot (Author) : http://awbot.sourceforge.net
CVSChangeLogBuilder (Author) : http://cvschangelogb.sourceforge.net
_______________________________________________
Dolibarr-dev mailing list
[email protected]
https://lists.nongnu.org/mailman/listinfo/dolibarr-dev
_______________________________________________
Dolibarr-dev mailing list
[email protected]
https://lists.nongnu.org/mailman/listinfo/dolibarr-dev
