Bonjour,
En fait la mauvaise manip que j’ai faites, c’etait de changer le champ de référence FK, qui était à Facture_Projet_Id à un autre champ, qui n’existe pas en base de donnée c’est pour ça que ça a partie en boucle.
OK on va essayer de reproduire cette manip mais je pense qu’au pire ça ne fait que générer des traces d’erreurs SQL, je ne vois pas trop pourquoi ça pourrait faire partir en boucle une instance… Je vous tiens au courant de nos tests
Merci pour ces infos,
Il y a dû y avoir un cycle dans les foreign-key et la construction de l’objet est peut-être partie en boucle, avant même de pouvoir générer une requête. Je pense que le problème est plus dans l’object loader. On va aussi chercher dans cette direction.
J’ai réussi à reproduire la cas sur un cycle de FK. Il suffit de créer 2 FK qui se référencent l’une et l’autre.
On va renforcer le code qui charge la hiérarchie des liens car effectivement setRootField part en boucle.
Voilà, il y aura désormais un message d’erreur dans les logs (et dans les audits de l’objet) si le chargement d’un objet métier trouve un cycle qui ramène une FK déjà traversée dans sa définition,
ce qui est impossible, car ça générerait une requête SQL avec une infinité de jointures.
L’objet ne fera pas ce qu’il faut (logs, trace SQL…) mais au moins il ne bloquera plus la plateforme.
c’est parfait surtout que l’erreur est trés commune sur cette partie dans le cas d’evol du modéle de donnée comme ce que j’ai eu à faire