Probleme de Mapping avec Sequence

**P4dre** · 17/12/2007, 10h13

Bonjour à tous,

J'ai un ptit soucis en ce qui concerne le mapping de ma colonne Id. Je vous fait un topo de l'ensemble du probleme puis je vous dirai ce que j'ai deja essayé sans succes ^^

Le probleme consiste a mapper une colonne qui est taggé @Id avec une séquence présente sur ma BD (Oracle). Le probleme c'est que ma colonne est un VARCHAR(4) et pour des raisons de compatibilité de version entre la version que je developpe et la version précédente, je ne peux la changer et la passer en INTEGER.

Vous voyez donc je suppose le probleme arriver : un magnifique class cast exception quand je fait un code comme celui ci :

Code :

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

1
2
3
4
5
 
@Id
@SequenceGenerator(name="XX_SEQUENCE",sequenceName="XX_SEQ")
@GeneratedValue(strategy=GenerationType.SEQUENCE, generator="XX_SEQUENCE")
private String myIdColonne;

Je ne peux me permettre de passer myIdColonne en int (meme si cela fonctionne , le cast automatique est fait, soit par oracle soit par hibernate mais il est fait...) car je doit ajouter des zero a gauche pour cette Id (contrainte métier)
Exemple : 28 ==> 0028

Je me suis donc dit que j'allais faire un service qui faisait une requete native afin de récuperer le NEXT_VAL de ma séquence et pouvoir le transformer en String. Cela marche tres bien... le GROS problème c'est que cette requete rend mon service DEPENDANT de mon SGBD actuel (Oracle) car il va tapper dans une table spécifique d'oracle (DUAL) et mon cahier des charges me l'INTERDIT.

Code :

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

1
2
3
 
StringBuffer sbRequete = new StringBuffer(128);
sbRequete.append("select XX_SEQ.nextval from DUAL");

Voyez donc mon impasse... je me demandais donc s'il existait un moyen d'utiliser le tag @GeneratedValue mais d'intercepter a un moment donner la valeur pour la transformer en String et mettre les zéros a gauche, ou bien s'il existait des objets JPA qui permettent d'aller tapper dans une sequence (sans le tag @GeneratedValue) sans etre dépendant de la BD.

Je prend n'improte quel piste car la je dois avouer que je suis a court d'idée

**JeitEmgie** · 17/12/2007, 13h32

Envoyé par P4dre

Bonjour à tous,

Je prend n'improte quel piste car la je dois avouer que je suis a court d'idée

En voici quelques unes :

1. AOP
2. @PrePersist
3. @Type (peut être dépendant de la couche persistence...)

**P4dre** · 17/12/2007, 14h24

Envoyé par JeitEmgie

En voici quelques unes :

2. @PrePersist

Je vien d'explorer l'idée... malheureusement l'évènement PrePersist est lancé avant l'attribution à mon Entity de l'Id généré... dommage

Envoyé par JeitEmgie

3. @Type (peut être dépendant de la couche persistence...)

En effet @Type est dépendant et malheureusement mon cahier des charges de l'interdit (foutu cahier des charges

)

Je vais regarder du coté d'AOP , en tout cas merci

Si d'autres personnes on des idées, n'hesitez pas !

**JeitEmgie** · 17/12/2007, 15h19

Envoyé par P4dre

Je vien d'explorer l'idée... malheureusement l'évènement PrePersist est lancé avant l'attribution à mon Entity de l'Id généré... dommage

En effet @Type est dépendant et malheureusement mon cahier des charges de l'interdit (foutu cahier des charges

)

Je vais regarder du coté d'AOP , en tout cas merci

Si d'autres personnes on des idées, n'hesitez pas !

indépendance de la couche persistance (hibernate, toplink, ...) != indépendance du SGBD (oracle, postgresql, ...)

de toute façon les générations de clé primaire étant toujours plus ou moins dépendantes du sgbd, quel est le couillon qui a imposé une contrainte aussi stricte dans un contexte où il faut rester compatible avec une version legacy ?

pour minimiser la dépendance vous pourriez avoir un mécanisme de "delegate" : vous auriez une interface définissant le protocole de communication entre le POJO et la classe formattant votre clé primaire, la classe étant définie en fonction du SGBD...
cela limiterait la dépendance au minimum...

car pour l'AOP, il faudra certainement descendre au niveau "method" ce qui implique AspectJ... et lui : il est compatible avec votre cahier des charges ?

alors à choisir...

**OButterlin** · 17/12/2007, 15h39

Pourquoi ne pas remplacer

Code :

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

1
2
sbRequete.append("select XX_SEQ.nextval from DUAL");

par

Code :

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

1
2
sbRequete.append("select max(id) from LaTableEnQuestion");

Du coup, c'est indépendant de la base...
A+

**P4dre** · 17/12/2007, 15h53

Envoyé par JeitEmgie

indépendance de la couche persistance (hibernate, toplink, ...) != indépendance du SGBD (oracle, postgresql, ...)

Oui je sais bien... mais je dois me restreindre aux spécif JPA et ne pas utiliser des choses propres a Hibernate ou Toplink ou autre...

Envoyé par JeitEmgie

quel est le couillon qui a imposé une contrainte aussi stricte dans un contexte où il faut rester compatible avec une version legacy ?

Je te le fait pas dire

Envoyé par JeitEmgie

car pour l'AOP, il faudra certainement descendre au niveau "method" ce qui implique AspectJ... et lui : il est compatible avec votre cahier des charges ?

Tu tappe de nouveau dans le mille... après avoir regardé AOP je ne peux pas l'utiliser

Pourquoi ne pas remplacer par

Code :

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

1
2
 
sbRequete.append("select max(id) from LaTableEnQuestion");

Parce que je gère des ambulances , et qu'il y a des éditions qui en découlent et que si la dernière ambulance est édité puis supprimé, l'ambulance suivante aura le meme numéro que la derniere qui a été supprimé... ==> Buz...

Pas évident mon histoire je vous l'accorde

**JeitEmgie** · 17/12/2007, 16h01

Envoyé par OButterlin

Pourquoi ne pas remplacer

Code :

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

1
2
sbRequete.append("select XX_SEQ.nextval from DUAL");

par

Code :

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

1
2
sbRequete.append("select max(id) from LaTableEnQuestion");

Du coup, c'est indépendant de la base...
A+

c'est une idée mais faire attention :

avec N users il faudra locker LaTableEnQuestion ...
donc transaction...
donc problème de contexte dans lequel est appelé ce code et risque de dépendance à un autre niveau du SGBD : les transactions en cascade...

dépendance d'autant plus subtile que celle-ci est implicite et donc risque de ne pas apparaître tout de suite...
(si qui soulève d'ailleurs une autre question : comment le cahier des charges impose-t-il de démontrer cette indépendance au SGBD ?)

NB
pour ce qui est des records supprimés : quelque chose empêche-t-il de les garder avec un status "deleted" ?

A envisager :
utiliser une clé primaire naturelle (un id incrémenté)
et
ajouter un champ "legacy" qui sera la clé "ancienne" version avec une contrainte d'unicité

**P4dre** · 17/12/2007, 16h16

Envoyé par JeitEmgie

si qui soulève d'ailleurs une autre question : comment le cahier des charges impose-t-il de démontrer cette indépendance au SGBD ?

Ce ne sera pas a moi de m'occuper de prouver cette indépendance, je n'ai pas d'infos sur la méthode qui va être utilisé, tout ce que j'ai sais c'est que pour la partie que je dèv je dois respecter cette indépendance.

Envoyé par JeitEmgie

pour ce qui est des records supprimés : quelque chose empêche-t-il de les garder avec un status "deleted" ?

Oui , je travaille sur "des tables de bases" qui ne doivent pas être modifiées... donc pas d'ajout d'une colonne "Valide" par exemple... j'y avait bien pensé

En tout cas je vous remerci de votre participation a ce magnifique casse tête informatique... c'est cool vous allez pouvoir maudir avec moi les gens qui ont pensé ce truc ignoble ^^

**JeitEmgie** · 17/12/2007, 16h19

Envoyé par P4dre

Ce ne sera pas a moi de m'occuper de prouver cette indépendance, je n'ai pas d'infos sur la méthode qui va être utilisé, tout ce que j'ai sais c'est que pour la partie que je dèv je dois respecter cette indépendance.

Oui , je travaille sur "des tables de bases" qui ne doivent pas être modifiées... donc pas d'ajout d'une colonne "Valide" par exemple... j'y avait bien pensé

En tout cas je vous remerci de votre participation a ce magnifique casse tête informatique... c'est cool vous allez pouvoir maudir avec moi les gens qui ont pensé ce truc ignoble ^^

vous ne pouvez pas ajouter de champs aux tables de base : ok...
mais pouvez-vous ajouter des tables "à vous" ?

**P4dre** · 17/12/2007, 16h23

Envoyé par JeitEmgie

vous ne pouvez pas ajouter de champs aux tables de base : ok...
mais pouvez-vous ajouter des tables "à vous" ?

Oui ... tu voudrais donc créer une table qui contiendrai la liste des ids qui sont "deleted" ?

Ca pourrai etre une solution en effet je regarde ça

**JeitEmgie** · 17/12/2007, 16h27

Envoyé par P4dre

Oui ... tu voudrais donc créer une table qui contiendrai la liste des ids qui sont "deleted" ?

Ca pourrai etre une solution en effet je regarde ça

non,

faites le modèle "intelligent" tel qu'il convient à l'application
et pointez en @OneToOne vers le modèle "débile"...
==
faites du nouveau modèle un wrapper de l'ancien...

**P4dre** · 18/12/2007, 11h33

Merci pour la solution , ça se passe en effet bien ainsi !

**cisco** · 20/12/2007, 13h02

je ne suis pas sur d'avoir compris la solution.
Autrement moi j'aurai essayer avec une "sequence table as generator"
http://www.oracle.com/technology/pro...TableGenerator

Probleme de Mapping avec Sequence

JPA Java

Discussions similaires

Partager

Partager