Je constate les deux anomalies suivantes au niveau de la vérification des clés fonctionnelles en v5 pour les objets liés :
Anomalie 1 : si un attribut de la clé fonctionnelle de l’objet lié est vide (attribut non obligatoire) la vérification ne fonctionne pas.
Anomalie 2 : si un attribut de la clé fonctionnelle de l’objet lié contient des espaces au début ou à la fin la vérification ne fonctionne pas (en v4 il n’y avait pas de trim, lorsqu’on passe en v5 en conservant les données créées en v4 on peut donc tomber dans ce cas).
Steps to reproduce
Sur une instance Simplicité v4.0.P25 (2022-11-10 00:35) j’ai créé les deux objets métiers suivants :
Le pays « None » n’a pas de code et le nom du pays « space » contient un espace au début et à la fin :
J’ouvre le formulaire de création d’une ville, je sélectionne le pays « None » et je mets « N » dans le champ « City » et j’enregistre. L’enregistrement se fait sans erreurs.
J’ouvre le formulaire de création d’une ville, je sélectionne le pays « space » et je mets « S » dans le champ « City » et j’enregistre. L’enregistrement se fait sans erreurs.
J’arrête mon conteneur Simplicité, je modifie mon docker-compose pour passer de Simplicité v4 à Simplicité v5 et je reconstruis le conteneur Simplicité :
Une fois la migration terminée, je me reconnecte à l’application.
Les données que j’avais créé en v4 sont toujours présentes :
J’ouvre le formulaire de création d’une ville, je sélectionne le pays « None » et je mets « N2 » dans le champ « City » et j’enregistre. [Anomalie 1] Une erreur s’affiche bloquant la création :
J’ouvre le formulaire de création d’une ville, je sélectionne le pays « space » et je mets « S2 » dans le champ « City » et j’enregistre. [Anomalie 2] Une erreur s’affiche bloquant la création :
J’ouvre le formulaire de création d’une ville, je sélectionne le pays « France / FR » et je mets « F » dans le champ « City » et j’enregistre. L’enregistrement se fait sans erreurs.
En V5 Simplicité renforce le contrôle de la référence lors du save = en vérifiant que le row_id de la référence matche bien les valeurs de la clé référencée, il y un trim qq part qui fait que la recherche ne trouve rien.
Nous n’avons jamais rencontré ces problèmes car en général :
une clé fonctionnelle est obligatoire : le code devrait être seule clé fonctionnelle obligatoire (et mettre N pour None par exemple), et d’ailleurs certaines bases n’acceptent pas d’index unique null, dans le cas d’une clé composite ça se discute en effet
la V5 force des “trim” et du coup il ne retrouve plus la référence lors du save : ça me semble injouable de revenir en arrière : il faut plutôt faire un update de votre colonne en forçant un “trim” lors de la migration, car en soit garder des espaces sur un champ clé posera d’autres problèmes (obligé de faire des trim à la main dans toutes les publications, test d’égalité en java, doublon fonctionnel entre " a" et “a” et " a "…)
On va regarder si on peut rendre le trim “passant” au save pour que ce ne soit pas limitant dans ces 2 cas de blocage.
Mais à mon avis c’est surtout un problème de qualité de données (pourquoi avoir des espaces ?) et de modélisation (code null ?).
Pour le premier point avec un champ de la clé fonctionnelle qui n’est pas obligatoire, le cas de mon exemple n’est pas parlant en effet mais on a des cas métiers où “null” dans un champ est une valeur qui a du sens.
Exemple : on a un objet contrat dont la clé fonctionnelle est composée de plusieurs champs dont le type (obligatoire), la date de début (obligatoire) et la date de fin (non obligatoire en fonction du type). Pour les contrats CDD, la date de début et de fin sont obligatoires (on ne peut pas créer 2 contrats CDD avec la même date de début et de fin pour un agent). Pour les contrats CDI, la date de début est obligatoire mais la date de fin ne l’est pas car si l’agent est toujours en poste la date sera null et s’il n’est plus en poste la date de fin sera non null.
Pour le second point, les utilisateurs ne font pas forcément attention aux espaces au début et à la fin (notamment s’ils font un copier/coller depuis word ou autre) et comme en v4 il n’y a pas de trim les espaces étaient conservées en BDD.
Je comprends tes remarques sur ce point, nous allons faire des requêtes SQL de redressement pour supprimer les espaces.
Suite à analyse dans Simplicité, on reproduit bien ces comportements. Il a fallu faire un update en base pour ajouter des espaces à ’ space ’ car on ne peut pas en V5 qui force un trim.
Champ clé null : historiquement Simplicité forçait en obligatoire tout champ clé fonctionnelle. Cette contrainte a été retirée pour permettre ce genre de paramétrage avec des clés composites / partiellement renseignée.
=> on va améliorer le service “populate” pour qu’il cherche bien avec un “is null” si un champ de la clé fonctionnelle est facultatif et vide. Actuellement ça remet la FK à vide (ce qui explique l’erreur de champ obligatoire côté UI).
Trim : là par contre c’est impossible de corriger ça, car ça impliquerait de faire une recherche non indexée sur la clé du genre where trim(colonne)='space' => il convient de faire une reprise de données pour garder de bonnes performances et éviter les doublons potentiels
('espace' et ' espace ' peuvent cohabiter et pour le métier c’est un doublon)
