Discussion :

[ellow]

Bonjour à tous,

dans mon application, j'utilise JPA (2.0) avec pour provider Eclipselink (2.3.1).

Pour les clefs primaires en base, je souhaiterais utiliser des séquences présentes sur le SGBD (Oracle).

Mais je voudrais pouvoir "intercepter" la valeur générée par les séquences pour la préfixer par des entiers de mon choix.

J'ai déjà effectué cela avec Hibernate, en étendant la classe org.hibernate.id.SequenceGenerator et en overridant la méthode

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

public Serializable generate(SessionImplementor session, Object obj);

.

Mais je ne parviens à reproduire cela avec Eclipselink.

Je sais comment utiliser des séquences du serveur.

Je sais comment créer ses propres séquences (comme c'est expliqué ici :http://wiki.eclipse.org/EclipseLink/...stomSequencing),

mais je ne parviens pas à utiliser une séquence du serveur pour en modifier la valeur générée.

Avez-vous une idée ?

Merci à tous !

[DevServlet]

Bonjour, même si cela est techniquement possible, je déconseille formellement ce type de pratique, pour la simple raison que les valeurs de séquence sont les informations centralisées et partagées par plusieurs clients accèdant à une table.Une autre application ayant besoin d'écrire dans une de tes tables sera obligée un jour d'attribuer une clé de séquence déjà présente dans ta table.Ou même lors d'une reprise de donnée manuelle avec des insertions en boucle sur cette clé de séquence.Peut on savoir pourquoi un tel besoin fonctionnel?

[ellow]

Bonjour,

merci de ta réponse.

En effet, je ne suis pas moi-même partisane de cette solution.

Il s'agit de préfixer les clefs primaires avec une valeur représentative d'une situation géographique des données.

J'opterais moi pour un champ réservé à cette donnée discriminante mais il s'agit d'une migration d'existant, incluant notamment le passage d'Hibernate vers JPA/Eclipselink.

Il ne s'agit donc pas de refonder la logique applicative ni la base de données.

Avez-vous des pistes, donc ?

Merci !

[DevServlet]

Bonjour,

merci de ta réponse.

En effet, je ne suis pas moi-même partisane de cette solution.

Il s'agit de préfixer les clefs primaires avec une valeur représentative d'une situation géographique des données.

J'opterais moi pour un champ réservé à cette donnée discriminante mais il s'agit d'une migration d'existant, incluant notamment le passage d'Hibernate vers JPA/Eclipselink.

Il ne s'agit donc pas de refonder la logique applicative ni la base de données.

Avez-vous des pistes, donc ?

Merci !

Bonjour, je comprends la problématique d'identifier une ligne de zone géographique,mais j'aurais proposé non pas de manipuler la clé primaire pour cette identification, mais d'utiliser plutôt une colonne de distinction dans la table.cette colonne ne pourrait contenir qu'un ensemble de valeurs constantes permettant explicitement d'identifier un secteur géographique.

[ellow]

bonjour,

merci pour cette réponse.

La solution que tu proposes est celle que j'évoque dans ma précédente réponse.

Malheuresement, cela ne répond pas à la problématique technique que j'expose dans ce topic.

Tant pis et merci quand même.

[DevServlet]

bonjour,

merci pour cette réponse.

La solution que tu proposes est celle que j'évoque dans ma précédente réponse.

Malheuresement, cela ne répond pas à la problématique technique que j'expose dans ce topic.

Tant pis et merci quand même.

Bonjour, Ok voici une solution qui marcherait dans ton cas,même si je n'approuve pas,mais je comprends que tu n'aies pas le choix.En fait tu peux utiliser une callBack Method. Tu surcharges la méthode @prePersist d'un listener que tu vas coller à ton entité. et dans cette méthode tu récupères ton identifiant et tu lui rajoutes ce que tu voulais.