Problématique JPA multi BDD et tests

Bonjour à tous,

ayant hérité d'une appli codée avec les pieds, j'ai décidé de tâcher d'améliorer au maximum le process qualité en injectant des données prédéfinie avant mes tests (et en supprimant après, classique en somme)
Pour des raisons de coût, nos tests se font piur l'instant sur les données existantes, ce qui empêche par exemple la réalisatino de tests complets sur nos web services...

Bref, ayant hérité d'une belle couche JPA que j'ai déjà décrassée autant que faire se peut, j'ai voulu utiliser HSQLDB comem base de test, permetant ainsi une vraie portabilité à mes tests.

- Premier soucis : HSQLDB, peut être couplé avec JPA, ne gère pas le cas ou mes entités n'ont pas de foreign key, pourtant nullable ! (Cas d'une entité "Location" avec une relation récursive... aucun problème sous mysql..)
=> c'est moi qui ait bugué ou c'est un fonctionnement 'normal' ?? :calim2:

- second soucis, ok HSQLDB ne gère pas les auto increments; qu'à cela ne tienne, j'ai généré un trigger pour mes tables.
Là ou le bas blesse, c'est qu'il n'est visiblement pas possible de préciser dynamiquement quelle strategie passer à mes id auto-générés via l'annotation "@GeneratedValue" ... (c'est pour cela que je préfère les confs xml aux annotations)

Bref, a prioi je vais passer par une autre base mysql pour faire mes tests proprements (via DBUnit) mais du coup, au revoir portabilité...

Avez-vous déjà rencontré de telles problématiques ? Ai-je complètement bugué sur un point essentiel ou JPA est-il si contraignant que l'on doive oublier toute portabilité entre bdd ? Merci d'avance pour vos retours, et à bas les ORM ! ^^

Euh, réponse rapide pour la seconde question, si HSQLDB gère un équivalent à l'auto increment (qui est une syntaxe spécifique à MySQL de souvenir).
C'est fait de la même façon que sous postgres, en utilisant IDENTITY:

Code:

---

CREATE TABLE vals (id INTEGER GENERATED BY DEFAULT AS IDENTITY, data VARBINARY(2000))

---

Pour la première, tu pourrais rephraser ton problème, car là je ne comprends pas des masses, même pour relation récursive tu peux avoir une foreign key.

Merci pour ta réponse Sinok, mais le coup de la génération d'identity, j'avais capté et ce n'est pas ce que je veux : idéalement (mais j'ai abandonné) j'aurais voulu ne pas avoir à effectuer la moindre action manuelle, et être capable "à la volée" de migrer mon système sous mySQL sous du Oracle avec des séquences) ou autre système !

Bref, avoir la même souplesse que sous spring avec conf xml + maven :p

Pour info, mon entité récursive qui bugue sous HSQLDB :

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17

@Id @Column(name = "ID") @GeneratedValue(strategy=GenerationType.IDENTITY) private Long locationId;   @Column(name = "LAST_UPDATE", nullable = false) @Temporal(value = TemporalType.TIMESTAMP) private Date lastUpdate;   @ManyToOne(optional = true, fetch = FetchType.LAZY, cascade = CascadeType.ALL) @JoinColumn(name = "PARENT_ID") private LocationEntity parent;   @Column(name = "VALUE", nullable = false) private String value;

---

Pour le coup, ça passait (je pouvais créé des Location sans "PARENT_ID") mais sous réserve de supprimer les contraintes sql... pas génial du tout pour ne pas dire nullissime...

Le problème de base vient du fait qu'Identity et Sequence ne sont pas supportés par l'ensemble des SGBD.

La seule solution portable totalement étant de passer par le generator Table et d'avoir une table qui maintient les ID.

Ou alors de faire la conf via XML (orm.xml) et de swapper la conf lors du build suivant les systèmes avec des tâches ant ou un build maven associé.

Merci, tu confirmes mes doutes quand au manque de souplesse de JPA, mais en même temps c'est inhérent à tout ce qui est "configuration écrite dans le code" :p (c'est d'ailleurs pourquoi à titre personnel je décourage ce genre de pratique avec ma team)

Salut,
ça doit pas être énorme de basculé de hsqldb à h2database, avec qui je n'ai jamais eu de soucis quand à son dialect hibernate pour ce qui est de l’incrémentation de clé primaire, et la syntaxe sql des deux sgbd doit être très voisine pour le cas ou il y ait besoin de charger des fichiers sql dans tes tests.
Pour ce qui est de passer tes données d'un sgbd a l'autre(avec migration de données) en faisant toute confiance à jpa/hibernate et la portabilité des dialect, c'est risqué, cette migration ressemble plus a du batch processing avec un peu plus de filtre que juste le mappage ORM.