Bonjour,
j’ai besoin de pouvoir décharger un objet massif qui pose des problèmes de limites de taille de record (erreur MySQL Row size too large).
J’ai dans un premier temps configuré une relation 1,1 vers un objet fils dans lequel j’ai déplacé un groupe de propriétés du père avec la fk du père définie dans le fils comme clé fonctionnelle. L’objet fils apparait donc dans les relations du père (links).
[EDIT] J’ai dans un deuxième temps configuré une relation 1,1 de l’objet fils vers le père (fk du fils dans le père, objet père dans les links du fils).
J’ai ensuite essayé de m’appuyer sur ce que je pense être la fonctionnalité standard d’incorporation des attributs de l’objet 'fils" lié à l’objet “père” dans l’espoir que la création d’un record “père” enchaîne automatiquement la création d’un record “fils” (dès que le row_id du père est connu). Comme ça ne fonctionne pas comme je le pensais, je me suis arrêté là sans chercher à aller plus loin sur cette piste.
J’ai alors configuré dans le père des champs non persistants (pas de champ physique) pour chaque attribut déporté dans le fils et géré en postSave du père une logique basée sur des onChange/isEmpty qui aboutit le cas échéant sur un getTmpObject du fils avec création ou select pour enregistrer dans le fils les modifications apportées dans le père. Toute cette mécanique fonctionne comme attendu (le fils est créé en postSave du père et les saisies dans les champs non persistants du père sont répercutées dans les propriétés du fils).
La solution retenue est-elle pertinente ou bien ai-je implémenté des mécanismes qui pourraient être pris en charge par le runtime ?
L’ancienne UI V3 implémentait ce flag “inline fields of 0,1 link into parent”.
Son usage ayant été de 1 objet durant 10 ans, il n’a pas été ré-implementé en V4.
On attendait que quelqu’un se réveille pour le remettre en haut de la pile ;-)
Ceci étant, c’est pas nécessairement une bonne idée d’introduire dans la couche logique un problème technique mysql, qui indique à ce sujet mais je suis pas expert :
d’utiliser des TEXT ou BLOB sur les champs longs
de passer la table en MyISAM plutôt que InnoDB
A l’origine le besoin était de dissocier par exemple une Adresse d’un objet Personne pour :
avoir 1 adresse principale directement dans la fiche personne (lien 1,1 inliné) mais bien dans la table Adresse = cette adresse pouvant servir par ailleurs comme Adresse de facturation sur une Facture
C’est exactement ce que ça faisait sans utiliser des champs tampons, mais directement les champs liés dans le formulaire.
De mémoire, il y avait une ambiguïté de modèle si un champ ramené X est obligatoire mais que le lien est optionnel 0,1 : si X non renseigné alors on supprime le lien ou erreur utilisateur ?
Il faut gérer le cas 0 avec une case à cocher pour dire s’il y a une adresse ou pas, rendant ensuite les champs d’une adresse obligatoires ou non.
Pour un lien 1,1 c’est beaucoup plus simple et ressemble plus au besoin de répartir les champs dans des tables, sans en faire nécessairement des objets métier = c’est comme sortir un FieldArea de la table.
En précisant un peu le besoin, il s’agit en effet d’un sous-ensemble de propriétés (plan d’action de mise en conformité) qui étaient rassemblées dans un objet (traitement de données personnelles). Initialement, le métier ne considérait pas le plan d’action comme un objet à part entière et les propriétés du plan d’action étaient directement saisies dans l’objet père (traitement de DP). Ils souhaitent désormais pouvoir dérouler des activités propres au plan d’action (qui reste afférent au traitement de DP) mais souhaitent conserver la possibilité d’éditer le plan directement depuis la fiche de traitement.
J’ai saisi l’opportunité de la prise en compte de ce nouveau besoin pour décharger cet objet traitement (>260 champs) et réduire le risque inhérent au “row size too large” en relocalisant ces propriétés dans le nouvel objet plan de mise en conformité et en essayant de les ré-incorporer (sans persistance) dans l’objet traitement de DP.
Je comprends que les options que j’ai tenter d’utiliser, sont des vestiges de la V3 et ne sont supportées ni en V4 ni en cible V5.
Si je suis le seul à soumettre la question, comme j’ai une solution qui fonctionne et que cette solution ne doublonne pas (à ce jour) les fonctionnalités du runtime, je vais rester là dessus tout en regardant de près si la situation évolue de ce côté :)
En regardant de plus près le paramétrage de l’incorporation, j’ai vu qu’il y avait une notion de link mapping permettant de lier des propriétés de l’objet père à des propriétés de l’objet fils (ce que j’ai paramétré pour mes tests sans succès). Est-ce bien une partie du mécanisme d’incorporation ou bien cela sert-il à autre-chose ?
C’est en effet exactement ce que je fais en ajoutant au tableau une clé fonctionnelle pour l’objet fils (la fk du père) l’élevant ainsi au grade “d’objet métier” et pas juste un conteneur d’attributs délocalisés. Mais la solution permettant de délocaliser des groupes d’attributs (exactement comme tu l’évoques) m’aurait enlevé une épine du pied avec mon “row size too large”…
Le LinkMap rien à voir, il sert à contraindre une relation = limiter les choix d’une référence pour respecter une égalité de champ.
Il doit y en avoir dans la Démo pour choisir sur un Contact une Commande du Client.
Quand on crée un Contact, on sélectionne un Client, puis une de ses commandes, ce filtre se fait par LinkMap pour ne pas proposer toutes les commandes à l’utilisateur, mais uniquement celles de ce client.
Dans ce cas le initRefSelect ne marche pas car côté back on n’a pas reçu le client sélectioné en front pour filtrer. En général, on s’en sort pour les besoins tordus (le client ou ses voisins) avec un call ajax (parametre sur l’objet) au change de la FK du Client pour prévenir le back pour les hooks qui viendront plus tard…
Super! Merci beaucoup.
Pour le LinkMap, j’avoue humblement ne pas avoir suivi tout les tutos je traîne donc quelques lacunes ;)
J’irai jeter un œil sur la démo pour me rafraichir là dessus.
@bmo
L’évolution de supporter les champs liés via une relation 0,1 ou 1,1 a été faite en V5.1.
Ce n’est pas backportable car impactant et doit encore passer pas mal de tests.
Exemple de lien 0,1 entre un Supplier et une Address.
La clé fonctionnelle de l’adresse doit contenir le fournisseur.
Le lien 0,1 doit avoir la propriété inline fields active
A l’affichage :
la liste “mono-ligne” est remplacée par le formulaire de l’objet lié
un bouton switch dans le titre permet de gérer le “0” du cas d’un lien optionnel (0,1) :
inactif : la zone est masquée (delete en base du lien si préexistant lors du “save” global)
actif : la zone s’affiche (création en base lors du “save” global avec les contrôles du validate)
si la relation est 1,1 : la zone sera toujours affichée
les champs de la foreign key sont masqués automatiquement (puisque c’est le formulaire parent)
les actions sont globales:
un seul bouton save pour sauvegarder chaque zone
étendre/réduire fonctionne globalement, etc.
tous les hooks du formulaire embarqué sont appelés (init, validate…).
la UI concatène les erreurs de toutes les zones avec des objets différents.
