Discussion :

[mazdahmen]

Bonjour a tous
au cour du développement de mon application web je me suis heurté a un problème qui m'a assez perturbé :
dans mon application l'utilisateur pourra a travers une page formulaire ajouter "Un plan d'action " (c'est une sorte de tableau qui contient des taches a exécuté) mais voila le problème , dans ma base de donné sqlserver j'ai une table ou sont stockés les plans d'action , la clé primaire de cette table est un compteur qui s'incremente de 1 a chaque nouvel enregistrement , Je voudrais disposer de la valeur de la clé primaire pour le plan d'action courant (en création) au chargement de la page de création et non après l'ajout de l'enregistrement .
J'ai pensé a récupérer au chargement de la page la valeur de la clé primaire du dernier enregistrement et l'incrémenter de 1 manuellement mais un risque de conflit se pose alors dans le cas ou 2 utilisateurs essayeront de créé un plans d'action au mémé moment . Est ce que le problème est clair ? j'aimerais savoir comment récupérer la clé primaire et éviter le problème de conflit .
merci

[cinemania]

la seule solution "possible" est d'instancier l'entité et de la persister, pour qu'elle dispose d'une clé primaire... ensuite par des updates, tu change ses propriétés...

il va donc éventuellement falloir soit que tu autorise null sur tous les champs, soit que tu trouve une autre solution, ou que tu n'utilise pas une clé auto-incrémenté sur cette table mais sur une autre qui va te servir de générateur de clé.

mais à quoi bon disposer dans ton formulaire de création de l'identifiant ?
tu n'affiche l'identifiant qu'une fois que l'élément a été persisté au moins une fois... je vois pas le problème.

Mais après tout dépend des technologies engagées... que tu travail avec un ORM ou que tu te tappe tout à la mano, normalement, toutes les entités de tes tables donnent lieux à des instances dans ton application, des instances d'objets qui reprennent grosso-modo les propriétés de la table associée...
de là que tu fasse référence à un objet quand tu créé les actions du plan d'action, avant que celui-ci ne soit créé, ne pose aucun problème... ni pour les actions ni pour les plans, tu défini dans les instances les clés et clés étrangères une fois que tu as persisté le plan d'action, puis persiste les actions dans lesquelles tu as propagés la clé fraichement obtenue.

Cela n'a rien de compliqué, suffit juste de prendre le problème autrement en considération, lors de la conception.

En effet dans ton monde objet, dans ton application ce qui compte avant tout c'est la référence vers une instance données, en SQL ce quii compte c'est la clé primaire, mais vu que tu créé les entités dans ton application, tu manipule donc des références vers des instances... donc tu peux propager les clés au moment de créer la persistance... au moins avec ce principe si la personne annule tout cela évite de supprimer de la base des entrées déjà crées pour des prunes.

[mazdahmen]

la seule solution "possible" est d'instancier l'entité et de la persister, pour qu'elle dispose d'une clé primaire... ensuite par des updates, tu change ses propriétés...

il va donc éventuellement falloir soit que tu autorise null sur tous les champs, soit que tu trouve une autre solution, ou que tu n'utilise pas une clé auto-incrémenté sur cette table mais sur une autre qui va te servir de générateur de clé.

mais à quoi bon disposer dans ton formulaire de création de l'identifiant ?
tu n'affiche l'identifiant qu'une fois que l'élément a été persisté au moins une fois... je vois pas le problème.

Mais après tout dépend des technologies engagées... que tu travail avec un ORM ou que tu te tappe tout à la mano, normalement, toutes les entités de tes tables donnent lieux à des instances dans ton application, des instances d'objets qui reprennent grosso-modo les propriétés de la table associée...
de là que tu fasse référence à un objet quand tu créé les actions du plan d'action, avant que celui-ci ne soit créé, ne pose aucun problème... ni pour les actions ni pour les plans, tu défini dans les instances les clés et clés étrangères une fois que tu as persisté le plan d'action, puis persiste les actions dans lesquelles tu as propagés la clé fraichement obtenue.

Cela n'a rien de compliqué, suffit juste de prendre le problème autrement en considération, lors de la conception.

En effet dans ton monde objet, dans ton application ce qui compte avant tout c'est la référence vers une instance données, en SQL ce quii compte c'est la clé primaire, mais vu que tu créé les entités dans ton application, tu manipule donc des références vers des instances... donc tu peux propager les clés au moment de créer la persistance... au moins avec ce principe si la personne annule tout cela évite de supprimer de la base des entrées déjà crées pour des prunes.

Merci cinemania pour ta reposne
Je dois dire Que j'ai pas tout pigé de ce que vous venez de dire ,surtout quand vous parlez d'instance et de reférence vu que je suis encore debutant dans le domaine .

la seule solution "possible" est d'instancier l'entité et de la persister, pour qu'elle dispose d'une clé primaire... ensuite par des updates, tu change ses propriétés...

j'ai deja pensé a cette solution que je trouve aussi assez logique . J'ai pensé a la creation d'un enregistrement avec des valeurs Nulls au chargement de la page et de l'updater ensuite dans le formualire , et dans le cas ou l'utilisateur voudra annuler ! j'ai songé a simplement suppprimer l'enregistrement Null créé et pour eviter d'effacer l'enregistrement d'un autre utilisateur qui est entrain de créé un plan d'action au meme moment j'ai pensé a recuperer la clé primaire de la l'enregistrement créé au chargement de la page et d'executer une requete "Delete ... where " .

Vous en pensez quoi de cette solution ?

mais à quoi bon disposer dans ton formulaire de création de l'identifiant ?
tu n'affiche l'identifiant qu'une fois que l'élément a été persisté au moins une fois... je vois pas le problème.

Dans ma page j'ai Deux contrôles ListBox ou l'utilisateur pourra effectuer du Drag & Drop de la première Listbox qui contient la liste de tous les utilisateurs du système vers la 2 ème ListBox qui elles stockera les personnes qui y sont ajouté dans une table ayant comme clé primaire l'identifiant de la personne et l'identifiant du plan d'action en creation et tout cela avant que l'utilisateur clique sur le bouton valider du formulaire !

Toute proposition est la bienvenue

[mazdahmen]

enfait en pensant a la solution proposé plus haut un autre probleme m'est venu a l'esprit , je parle du cas ou l'utilisateur aura cliqué sur le bouton fermer du navigateur ( la croix rouge toute en haut a droite) parceque dans ce cas l'enregistrement NULL ajouté dans la table ne sera pas supprimer :/ .
Quelqu'un a une meilleur solution a proposé SVP ?