Salut,
Tu as probablement / peut-être vu dans le code eqlogic.ajax, que c’est le save de l’eqlogic en premier (donc ton postSave ce fait juste après), ensuite le save des commandes
l’info qu’on a pas: sendNewConfig() va chercher la config où? dans les « commandes » de ton équipement?
si oui, tu auras déjà fait le lien => au moment de ton sendNewConfig() les commandes ont les anciennes données à ce moment; voila pourquoi il te faut 2 save pour avoir la bonne config.
ligne 605 tu vois le postAjax, fait lorsque les commandes sont déjà sauvées
Non, pas de problème de cache, c’est bien « la DB qui n’est encore pas à jour »
le postAjax est littéralement la première chose qui est faite juste après la sauvegarde de toutes les commandes.
un changement d’activation de l’équipement n’est effectivement pas géré par cette méthode (c’est pas un « action »==« save »)
je vois deux options vite fait mais il y en a surement d’autres:
- tu changes ta structure de données (et tu sauves tes configs dans une attribut configuration de ton équipement par exemple, cf. quelques plugins officielles qui font ça, comme plugin-mode de mémoire, je pense qu’il est publique); plus de boulot
- tu gardes ton postAjax mais pour gérer le cas de l’activation/désactivation tu gères plutot un
preSave()dans lequel tu dois détecter si l’eqlogic est activé/désactivé (hint:$thisc’est le nouveau,$old = eqLogic::byId($this->getId());c’est l’ancien
) et tu agis en conséquence sur ton démon juste pour cette partie pour activer/désactiver ce qu’il faut (sans te préoccuper de toute la config)