Contrôle de la génération DDL dans Toplink Essentials

Question

Je rencontre des problèmes avec la génération DDL de Toplink Essentials. Je développe une application basée sur Glassfish 2.1 et j'utilise JPA pour la persistance.

J'ai un graphe d'objet dans lequel une entité mère de classe A est propriétaire d'un ensemble d'entités de la classe B. B sont en Entités mises plusieurs saveurs qui Modélisée à l'aide d'héritage. Une telle saveur est une entité composite de classe BC qui regroupe un ensemble de plusieurs autres entités. Tous les entits B dans un BC doivent aussi appartenir à la même entité A que B. Notez que tous les entits B d'une entité A ne doivent pas faire partie d'un BC composite, ils peuvent aussi être autonomes.

Donc, fondamentalement, que les cartes aux classes suivantes:

@Entity 
class A { 
    @ManyToOne(mappedBy="owner", cascade = { CascadeType.PERSIST, CascadeType.REMOVE }) 
    Set<B> bs; 
} 

@Entity 
@Inheritance 
abstract class B { 
    @Id 
    long id; 

    @ManyToOne(cascade = { CascadeType.PERSIST, CascadeType.REMOVE }) 
    A owner; 

    @ManyToOne(optional = true) 
    BC composite; 
} 

@Entity 
class BC extends B { 
    @OneToMany(cascade = { CascadeType.PERSIST, CascadeType.REMOVE }, mappedBy = "composite") 
    Set<B> parts; 
} 

Lorsque TopLink génère le DDL pour cette hiérarchie d'objets crée toutes les clés étrangères comme prévu. Cependant, il ne définit pas de règles en cascade pour les contraintes.

Lorsque je tente maintenant de supprimer un graphe d'objet entier via une référence à la Une instance il peut y avoir des situations où TopLink ne parvient pas à éliminer correctement le graphique de la base de données. Lorsque toplink supprime une entité BC avant de supprimer les entités B contenues, la contrainte de clé étrangère pour la relation "composite" est violée.

Cette situation peut être corrigée en ajustant manuellement le produit à CASCADE DDL (ou SET NULL) sur la contrainte de clé étrangère pertinente qui est très bien pour un environnement de production. Ceci échoue cependant dans un environnement de test avec des bases de données en mémoire (Derby) où la génération de DDL est entièrement gérée par les éléments essentiels de toplink et conduit ainsi à la violation de contrainte décrite ci-dessus.

Existe-t-il un moyen d'influencer le processus de génération DDL de telle sorte que les règles de cascade requises soient correctement définies par les éléments essentiels du toplink?

Merci pour votre aide!

Answer 1

Ce n'est pas un problème avec la génération DDL, mais avec la suppression.

TopLink Essentials a rencontré des problèmes lors de la résolution de suppressions à partir de graphiques d'objets complexes ou de relations cycliques. Il existe quelques solutions de contournement, telles que la suppression des objets dépendants en premier et l'appel de flush, puis la suppression des autres objets ou la définition de la clé étrangère sur null afin qu'ils soient mis à jour. L'utilisation d'un personnaliseur pour marquer le mappage privateOwned ou jouer avec la dépendance de contrainte peut également fonctionner. Vous pouvez également laisser tomber ou différer les contraintes.

Tous les problèmes de suppression ont été corrigés dans EclipseLink. Par conséquent, la mise à niveau vers la dernière version d'EclipseLink devrait résoudre le problème. EclipseLink prend également en charge une annotation @CascadeOnDelete pour ajouter la cascade à la contrainte dans la génération DDL.