Discussion :

[arcandre]

Bonjour à tous,

Après des semaines de recherches, je me décide à faire appel à vous. Je vous explique mon problème : j'ai des objets (modèles de machines) qui doivent être reliés à des composants. La base contient 50.000 composants et chaque modèle de machine peut être relié à plusieurs milliers de composants (relation n-n). Ma question est toute simple : comment faites-vous pour relier des composants à un modèle de machine ? Si je créé un formulaire de modèle de machine et que je rajoute le champ "composants", Symfony2 me génère automatiquement une dropdown de 50.000 composants. Si j'utilise le bundle genemuFormBundle, avec le widget autocomplete, je n'ai plus de méga dropdown, mais j'ai un input caché qui contient un json avec l'id et le label des 5430 composants reliés à mon modèle de machine. Autant vous dire que ça rame sévère.

Avez-vous déjà été confronté à ce genre de problème ? Je commence à me demander si Symfony2 est fait pour des applications professionnelles avec de grosses bases de données relationnelles... ou si je m'y prends comme un manche

D'avance merci pour votre aide et très bonne soirée

[rawsrc]

Salut,

je ne connais pas sf2 mais je peux te dire que l'approche avec l'autocomplete est la meilleure. Pour ne pas mettre à genoux ton serveur, Il faut juste que tu paramètres ton widget afin qu'il n'utilise pas d'input caché mais envoie à chaque touche entrée une requête ajax et qu'il récupère ainsi les résultats au fur et à mesure. Ton sql générant le résultat doit être limité à par exemple 20 ou 30 enregistrements.
J'ai utilisé cette approche dans mon dernier dev avec une base de données de plusieurs millions d'éléments tous interconnectés et ça a roulé impec.

[arnooo999]

Bonsoir,

Effectivement l'approche autocomplete est la meilleure.

Mais à mon sens le problème essentiel est de charger en mémoire les 5000 entité composants lié à une machine,que ce soit avec symfony, en php "artisanal" ou dans un autre langage, cela ne peut que provoquer des ralentissements.
D'autre part je doute que du point de vue de l'utilisateur cela soit exploitable.

Tu pourrais créer une entité "Composition" (has one Machine, has one Composant) qui remplacerait ton ManyToMany, puis faire une pagination sur les entités Composition lié à une machine donnée, avec des boutons supprimer/ajouter (avec action Ajax).

[arcandre]

Bonjour Messieurs,

Tout d'abord, merci pour vos contributions. J'ai effectivement choisi l'approche "autocomplete" qui permet d'éviter de générer des dropdown de 100.000 lignes. En revanche, mon second problème reste entier : pour bien faire son travail, Symfony exige qu'on lui communique l'objet entier, avec tous les paramètres ajoutés au formulaire. Donc si je veux créer un formulaire d'édition de modèle de machine qui permette de renseigner leur libellé et leurs composants associés, je devrai envoyer à Symfony les informations suivantes :
- libellé : modèle23
- composants : [{"value":85547,"label":"component12"},{"value":85548,"label":"component13"},{"value":85549,"label":"component14"},{"value":85550,"label":"component15"},{"value":85551,"label":"component16"},{"value":85552,"label":"component17"},{"value":85553,"label":"component18"},{"value":85554,"label":"component19"},{"value":85555,"label":"component20"},{"value":85556,"label":"component21"},{"value":85557,"label":"component22"},{"value":85558,"label":"component23"},...

Donc si mon objet est relié à 7500 composants, je dois envoyer au contrôleur un JSON qui contient les informations relatives à ces 7500 composants, et ce même si je n'ai rien modifié ! Si j'ai la moindre erreur dans ce JSON, Symfony détruira tous les liens et mon modèle de machine perdra ses 7500 composants. En bref, c'est la merde. Je n'arrive pas à comprendre que les gars de Symfony n'aient pas pensé à ça. Je dois forcément mal m'y prendre...

Encore merci pour votre aide en tous cas

[ascito]

et tu ne pas pas sur par exemple

- libellé : modèle23
- composants : [{"value":85547,"label":"component12"},...


commencer à filter à partir de 85; cad tout LIKE 85%, mais jamais avant d'avoir la clé composant 85, ou peu être faire une recherche sur chaque clé + clé +1

si champs = 1
search si existe 10%, 11%,12%,13%,14%...19% groupe by value => afficher 10 , 12

si champs = 11
search si existe 110% , 111%, 112% 113% etc groupe by value => afficher 112 , 113 etc

etc ?


je ne vois pas ce que ça représente comme ressource tel quel, mais ca me paraitrais logique, et c'est ce que propose rawsrc du coup, j'ai l'impression

[arcandre]

et tu ne pas pas sur par exemple

- libellé : modèle23
- composants : [{"value":85547,"label":"component12"},...


commencer à filter à partir de 85; cad tout LIKE 85%, mais jamais avant d'avoir la clé composant 85, ou peu être faire une recherche sur chaque clé + clé +1

si champs = 1
search si existe 10%, 11%,12%,13%,14%...19% groupe by value => afficher 10 , 12

si champs = 11
search si existe 110% , 111%, 112% 113% etc groupe by value => afficher 112 , 113 etc

etc ?


je ne vois pas ce que ça représente comme ressource tel quel, mais ca me paraitrais logique, et c'est ce que propose rawsrc du coup, j'ai l'impression

Je crois que je me suis mal exprimé. Il y a deux problèmes bien distincts :

1. Le menu déroulant affiché à l'utilisateur qui permet à celui-ci de faire ses choix. Par exemple : je veux relier ce modèle de machine aux composants 25, 456, 87511,... Ce problème est déjà résolu puisque j'ai choisi un système de type autocomplete.
2. Les informations cachées qui sont envoyées au contrôleur de Symfony2 lors de la soumission du formulaire. En particulier, j'ai un <input type="hidden"> qui contient le tableau JSON que j'évoque plus haut. Pour que Symfony2 puisse accepter la soumission du formulaire d'édition, ce JSON doit contenir la liste intégrale des composants que l'utilisateur a décidé de relier à son modèle de machine. On peut donc avoir un JSON composé de plusieurs dizaines de milliers d'items (par exemple, une voiture est composée de milliers de composants). C'est la qu'est mon problème, a priori insoluble : je ne peux pas réduire cette liste sans que Symfony2 l'interprète comme une volonté de supprimer des liens modèle <=> composants

Voilà, j'espère que j'ai été un peu plus clair

[arcandre]

Bonsoir,

Effectivement l'approche autocomplete est la meilleure.

Mais à mon sens le problème essentiel est de charger en mémoire les 5000 entité composants lié à une machine,que ce soit avec symfony, en php "artisanal" ou dans un autre langage, cela ne peut que provoquer des ralentissements.
D'autre part je doute que du point de vue de l'utilisateur cela soit exploitable.

Tu pourrais créer une entité "Composition" (has one Machine, has one Composant) qui remplacerait ton ManyToMany, puis faire une pagination sur les entités Composition lié à une machine donnée, avec des boutons supprimer/ajouter (avec action Ajax).

Ca y'est je viens de comprendre ta réponse à la quatrième lecture

Je commence à voir l'intérêt de l'entité composition que tu évoques, surtout parce qu'elle pourrait m'aider à faire la requête suivante :
"Sélectionner tous les composants qui ne sont pas reliés à ce modèle de machine". Vu que j'ai une table de relations entre modèles et composants, je n'arrive pas à la faire avec le queryBuilder de Doctrine.

En revanche, j'ai du mal à saisir comment cette nouvelle entité résoudra mon problème de champ caché gargantuesque... Il faudra bien que les liens existants, i.e. les compositions, soient présents (bien que cachés) dans le formulaire non ?

La seule solution que je vois c'est de ne pas saisir ces relations modèles <=> composants dans le formulaire des modèles, mais comme tu le dis via une autre interface.

[ascito]

J'ai repensé au problème,

quand tu achète une voiture, tu n'a jamais la notice de toutes les pièces de la voitures

quand tu achète une voiture, personne ne te demande l'ensemble des pièces qui permettent d'usiner ses dites voitures.

hors, tu voudrait faire passer l’ensemble de tout ca...

Je reste donc sur un avis one to cat, peut être simple et spécialisé, mais au moins compatible avec php