[Dolibarr-dev] patchCategorie

[anthony . poiret]

Bonjour à tous,

Ci-joint un petit patch pour categorie.class et les scripts de  
migrations et de table MySQL associés.

Il corrige le problème d'unicité des label dans l'arbre des  
catégories. J'ai du rajouter un champ à la table llx_categories pour  
identifier le parent plus simplement, et modifier ses contraintes  
(l'anciennes contrainte d'unicité liait label, type et entité, sans  
prendre en compte le parent puisqu'il n'existait pas dans la table).

En parlant de cela, j'ai bien compris l'intérêt des tables  
d'association catégories/objets (sociétés, produits, etc...) puisqu'un  
catégories peut comprendre plusieurs objets et un objet appartenir à  
plusieurs catégories.

Cependant, la table d'association de catégorie avec elle même  
m'échappe quelque peut: qu'une catégorie puisse avoir plusieurs filles  
me parait en effet évident, mais il me semble qu'une fille ne puisse  
avoir qu'une ou pas de mère. L'utilisation d'une table d'association  
me parait donc superflu.

Je n'ai pas retouché toute la classe (mon objectif était de parvenir à  
remettre en route le module magento), mais je pense qu'on pourrait  
éviter une multitude de join et de difficultées liées à cette table  
d'association en utilisant un champ répertoriant le parent plutôt  
qu'une table d'association.

Cordialement,
AnthonyP

translation:

Hello everyone,

Attached a small patch categorie.class, migration scripts and MySQL  
table associated.

It corrects the problem unicity of the label in the tree of  
categories. I had to add a field to the table to identify the parent  
llx_categories more simply, and modify its constraints (the old unique  
constraint bound label, type and entity, without caring of the parent  
because there was not in the table).

Speaking of which, I understand the interest tables Association  
classes / objects (companies, products, etc. ...) because a category  
may include multiple objects and an object belong to multiple  
categories.

However, the association table with itself eludes me somewhat: a  
category can have many daughters seems to me evident but it seems to  
me that a daughter can have one or no parent. So the use of an  
association table seems to me superfluous.

I have not reworked the whole class (my goal was to back on the road  
the magento module), but I think we could avoid a multitude of issues  
and of joins regarding this association table using a field rather  
than listing the parent in an association table.

Cordially,
AnthonyP

patchCategories30-31.txt
Description: Text document