Dynacase » Platform » Core

Contexte :

Lors d'une synchronisation, on manipule jusqu'à une 100aine de documents de manière concomitante or après analyse la méthode la plus appelée et la plus longue est usort du fait de l'application à de très nombreuses reprises de masque (environ 15% du temps de la synchro devant les temps BdD).
Or ceci provient de l'utilisation de ces masques à chaque [get|set]AttributeValue, FormatCollection::render est aussi impacté...
C'est dommage car après relecture du code ce masque n'est d'aucune utilité dans ce cas (il n'est pas pris en compte dans le formatage de l'attribut), il est juste appelé lors du getAttribute.

==========================================================================================================================================================================

Proposition de solution :

Il y a de nombreux usages où un attribut complet n'est pas nécessaire.
Or, Doc::getAttribute est assez lourd (notamment parce qu'il appelle applyMask)

pour ces cas particuliers, un objet allégé pourrait suffire.

En particulier, les appels à Doc::getAttributeValue utilisent getAttribute (https://github.com/Anakeen/dynacase-core/blob/38889752d67fb1708446f5e176a1574159a86ed3/Class/Fdl/Class.Doc.php#L3119) pour le transmettre à Dcp\AttributeValue::getTypedValue (https://github.com/Anakeen/dynacase-core/blob/38889752d67fb1708446f5e176a1574159a86ed3/Class/Fdl/Class.Doc.php#L3127) alors que cette dernière méthode n'a besoin que des éléments suivants :

• propriétés
  • id
  • type
• méthodes
  • isMultiple
  • isMultipleInArray

Il y a 2 approches possibles 

• ajouter un paramètre $withoutMask = false à la méthode Doc::getAttribute
  • Avantages
    • les changements de code sont minimes
  • inconvénients
    • amène de l'ambiguïté : lorsque j'ai un normalAttribute, puis-je faire confiance à sa visibilité ?
• créer un objet lightAttribute et une méthode Doc::getLightAttribute
  • Avantages :
    • on crée réellement un objet allégé (plutôt que de simplement diminuer les traitements)
    • on évite toute ambiguïté : un LightAttribute n'est pas un NormalAttribute
  • inconvénients :
    • nécessite plus de modifications de code
  • contraintes
    • il serait plus sain de remplacer les méthodes isMultiple et isMultipleInArray en propriétés (pour avoir un objet déclaratif)