Discussion :

[giviz]

Re Bonjour!

J'utilise des tables pour gérer le contenu des listes déroulantes de mon IU.

Actuellement je procède comme ca:

- J'ai une table système par liste qui définie les entrées existantes
- J'ai une table d'activation qui par liste qui définie les entrée activées parmis celles disponibles dans la table système.
- Je stock dans les tables de données l'id de l'entrée choisie avec un FK pour les traitement en cascade.

Seulement ca me pose des problèmes au niveau du code d'exploitation.

Si un user choisie un entrée dans la liste déroulante et que pendant ce temps un autre change la config et rend non disponible cette entrée ca part en sucette.

Pour pallier à ce problème je suis obliger de mettre en place pas mal de tests de controles.

Une autre idée m'est venue

Etant donner que je vais utiliser une interface XUL, avec la possibilité de faire des listes déroulantes éditables, je pensais laisser directement à l'utilisateur la possibilité de rentrer un nouveau choix (donc il n'a pas à passer par les outils de config pour ca) ou de choisir un choix parmis ceux existant déjà dans les autres tuples.

Mais admettons qu'il fasse une faute de frappe, aie, aie, aie ca va poluer toutes les listes et retrouver la bonne fiche dans laquelle l'erreur a été faite ne vas pas etre de la tarte pour lui...

Donc je ne sais pas trop comment m'y prendre, surtout que j'ai plein de listes comme ca à gérer...

Si vous avez des idées

[ego]

Au lieu de nous présenter une solution, pourrais-tu d'abord nous exposer ce que tu as à faire.
Dans tes messages, tu exposes souvent ce que tu as mis en place sans présenter le problème initial. C'est donc difficile de juger ta solution et de répondre aux problèmes que tu éprouves car on ne sait pas vraiment quel est le truc initial à résoudre, son objectif.

[giviz]

Merci pour ta remarque constructive, je vais tenter de réctifier ma facon de rédiger mes posts!

Donc ici le problème est le suivant:

J'ai un système multiutilisateurs.
Ce système sert à gérer des fiches.
Ces fiches ont des listes déroulantes sur certains champs.
Les entrées disponibles pour chaque liste sont stockées en bdd.

Je ne vois pas quelle solution appliquer pour gérer les entrées disponibles dans chaque liste sans avoir de conflits ?

C'est plus clair ?

[ego]

Il ne faut pas gérer les sélection en BD mais dans des variables, en mémoire, propre à chaque session utilisateur

[giviz]

Je ne comprend pas ta réponse :/

Les séléctions sont gérées en mémoires puis sauvées en base de données.
Mon problème vient du fait que si une des séléctions en mémoire n'existe plus en base de données au moment de son écriture, alors ca va merder.

[Bruno75]

ce genre de problème doit en général être géré au niveau de ton middleware de persistance qui se charge en particulier de la synchronisation et te permet entre autres de choisir un verrou pessismiste ou optimiste.

ou directement avec la base, à l'aide de l'intégrité référentielle de ta base qui, au moment de la modification, va te signaler une erreur. Tu n'as qu'à prendre en compte l'erreur et la signaler à l'utilisateur, nettoyer ton tampon mémoire, ... C'est en général dans le composant connection que tu vas spécifier le type de verrou.

[Bruno75]

Mon problème vient du fait que si une des séléctions en mémoire n'existe plus en base de données au moment de son écriture, alors ca va merder.

eh, oui. Dans ce cas tu n'as qu'à le signaler à l'utilisateur par un message du type "Un autre utilisateur a effacer la sélection en cours, opération de modification impossible" ou autre chose. (verrou optimiste)

Ou sinon, interdire la modification par deux personnes différentes(verrou pesimiste)

[giviz]

Oki donc je vais me pencher sur un système de lock de la config ou sur un système de controle avant validation.

Je devrais m'en sortir

Merci beaucoup

[ego]

Petite remarque...

La solution technique à ton problème est une chose. Le fait que la situation que tu as décris survienne d'un point de vue fonctionnel en est une autre et doit être analysée avant de plonger dans toute solution technique.
En effet, qui/quoi vas-tu "locker", les données lues par les lecteurs (ceux qui sélectionnent dans tes listes) ou les données en cours de modification par les "modificateurs". Même si tu fais cela, que vas-tu faire si un lecteur lit les données, va au toilettes pendant 20 minutes (!! ) et qu'entre temps un "modificateur" modifie la liste en BD ? Tu ne peux résonnablement pas locker la liste en BD pendant que le lecteur est aux toilettes. De même, si tu lock la liste pendant la modification, cela ne servira pas à grand chose pour ton lecteur qui a déjà chargé la liste.

Bref, ton problème possède peut être plutôt une solution du côté de l'utilisation, ultérieure, des données sélectionnées qui peuvent ne plus exister au moment de leur utilisation.

[giviz]

Je pourrais également appliquer ici le conseil que tu m'as donner sur mon autre post. A savoir utiliser une variable que j'incrémente à chaque fois que la configuration change.

Ainsi je ne verrouille rien, mais avant de valider mon enregistrement ou ma maj en base de données, je controle que la variable de la liste à toujours la meme valeur, si ce n'est pas le cas alors j'annule l'enregistrement et j'en averti l'utilisateur.

Comme ca personne n'est bloquer.

Ca te parrait bien ?

[ego]

tout à fait !

[giviz]

Cool !

[Franckintosh]

Le problème avec le verrou optimiste est que cela permet plusieurs "modificateurs" en simultané et lorsque c'est le cas c'est le premier qui soumet qui gagne. Or il peut être mieux qu'il n'y ait pas plusieurs "modificateurs" en simultané.
A étudier en fonction des besoins et contraintes de ton système.

[giviz]

Oui bonne remarque, j'en tiendrais compte une fois que les besoins auront étés fixés dans le modèle, pour commencer le technique.

Merci