Gestion de clés primaires

Bonjour,

Je souhaite créer un EJB afin de gérer les clés primaires de mes tables.
Par exemple, j'ai une table CLIENT, à laquelle je souhaite affecter une nouvelle clé primaire générée automatiquement (par incrémentation de 1) à chaque création de client.

Je travaille sous Eclipse 3.1 et Struts, et il me manque donc une méthode qui reprenne toutes les clés primaires, choisisse la plus éloignée de 0 pour procéder à une incrémentation et générer la nouvelle clé.

Je précise que je suis débutant.

Merci à vous.


[Modéré par Didier] : ajout de tag dans le titre - Les règles du forum Java

Je ne suis pas sûr que la création d'un EJB soit la bonne solution.
Une classe Java classique me semble mieux.
Ensuite, peux-tu nous dire quelle base de données tu utilises car dans Oracle, par exemple, tu as la notion de "séquence" qui fait cela pour toi ?

Salut Ego,

Merci de ta réponse.

En fait je travaille sur un projet existant basé sur Struts. La partie métier est gérée par des EJB et pour garder l'homogénéité de l'application je dois les utiliser afin d'accéder à la base.

Ma base de donnée est PostgreSQL, mais je dois travailler uniquement en EJB-QL et à première vue, il ne me semble pas possible d'y mettre des séquences. En outre, il me semble possible, à travers une méthode créé dans un EJB session, d'extraire les clés primaires, et de les trier pour déterminer le numéro le plus éloigner de 0 afin d'en créer un nouveau par incrémentation.

Toutefois, je pense pouvoir tirer la solution de la classe Java classique que tu as évoquée, ce qu'il me manque c'est l'algorithme du trie. C'est tout bête je sais, mais je suis pas foutue de faire cet organo. Merci pour ton aide.

Attention à ne pas tout mélanger.
Struts et EJB n'ont rien à voir ici.
La problématique de persistance des données est probablement traitée dans ton application côté "serveur", là où son tes EJBs. Tes EJBs peuvent tout à fait faire appel à des classe Java classiques.
Il n'y a aucune raison pour rester "homogène" mais si tu veux t'encombrer de la lourdeur d'un EJB pour cela, libre à toi.
Dans PostgreSQL tu as comme dans Oracle la notion de séquence, il ne te reste qu'à en créer et à en encapsuler l'usage dans une classe Java toute classique !!
cf. http://www.postgresql.org/docs/8.1/i...-sequence.html

L'avantage de passer par la base c'est que les problèmes d'accès concurrent sont gérés pour toi !

Mais ou va t-on..

Du définis un champs auto-increment dans ta base de données et puis c'est tout.

Depuis quand on a recourt à des EJB pour gérer des index ou des clefs...Je comprend meme pas cette phrase.

Attention à ce que tu dis !
ok pour la remarque sur les EJBs mais la notion d'autoincrement n'existe pas dans toutes les BD !!!
En plus, il peut être nécessaire de mieux maitriser l'allocation des clés primaires, soit pour des contraintes de format de la clé, soit pour pouvoir, au niveau d'un framework de persistance, gérer les clé étrangères !

certes certes.... :oops:
Dans ce cas la en tout cas, je pense réellement que cela suffit.
Il y'a trop souvent des projets ou on utilise un basouka pour tuer une mouche. Je trouve dommage de ne pas rester sur des choses simples.

Et la j'extrapole mais c'est tout le probleme de J2EE et de tous les frameworks dérivés. Il y'a tellement de chose que les gens cherchent forcement à utiliser tout pour le moindre projet.

Question 1: quelle bdd ne supporte pas l'auto-increment ?
Question 2: peux tu développer

Citation:

---

En plus, il peut être nécessaire de mieux maitriser l'allocation des clés primaires, soit pour des contraintes de format de la clé, soit pour pouvoir, au niveau d'un framework de persistance, gérer les clé étrangères !

---

Merci ego pour tes conseils et explications.
Et désolé pour ma fougue :wink:

Pour info, dans le livre "EJB Design Patterns", le chapitre 5 expose trois méthodes de génération de clé primaire.

Ce livre est téléchargeable gratuitement au format pdf, sur TheServerSide.com.

Merci à tous pour vos réponses.

Pour info: je débute et celà dans un stage pas facile ou il m'ai demandé beaucoup, c'est évident alors que je puisse prendre des mauvaises pistes.