On delete restrict et exception

Bonjour !

Je suis en train de me mettre à JPA.
Prenons un exemple d'une relation complexe (n par n), comme celle de la commande et des produits qu'elle contient.
Vous supprimez une commande, les lignes de la commande disparaissent en même temps (en ayant precisé un cascadetype.all dans l'entity commande).
Vous supprimez un produit, s'il n'y a pas de ligne de commande, vous pouvez supprimer le produit.

Comment on fait ça ?

Je voudrais aussi savoir comment attraper l'exception qui en résulte.
J'ai mis un catch pour javax.persistence.persistenceexception mais ça n'aide pas beaucoup comme information.

Merci à tous !

Code:

---

Vous supprimez un produit, s'il n'y a pas de ligne de commande, vous pouvez supprimer le produit.

---

Tu veux savoir comment detecter si un produit est concerné par une ligne de commande? une petite requete suffit non?

Non, j'aurais pu résoudre le problème comme ça mais ce n'est pas ce qu'on fait généralement quand tu veux supprimer un produit.

Quand on a la base et que tous les on cascade restrict sont mis en place et que tu fais un DELETE * FROM PRODUITS, s'il y a des lignes de commandes, SQL va te dir : na na, pas possible.

Tout simplement parce qu'il y a un ON DELETE RESTRICT sur la clé étrangère.

Bref, voilà, comment ça se passe avec JPA ?

A mon avis tu peux pas gérér ça par annotation, mais en revanche programmatiquement ca le fait bien, avant de supprimer un produit, tu testes s'il n'est pas rattaché à une commande.

Est ce que ça veut dire qu'il faut que je prenne en compte aussi lorsque je veux faire du ON DELETE SET NULL ?
En fait toutes les autres contraintes, faut que je les gère à la main ?

Ca devient lourd !
Je viens de le voir : autant utiliser les namedqueries et créer la base directement sans passer par aucun entities non ?!

Qu'est ce que t'en penses pour un projet qui aurait dû avoir 17 entities, maximum 20 ou 25 (mais je pense que ça va rester en dessous de 20).

Je veux dire, les ORM sont là plus quand t'as une base énorme avec 100 tables non ? Là ça simplifie la vie. Mais jusqu'à combien de tables on peut dire qu'on peut s'en passer ?

Est ce qu'on peut utiliser les namedqueries sans utiliser les entities ? C'est exactement comme ça que je les aurai implémenté si JPA n'existait pas. J'aurais fait des classes qui representeraient mon modèle et je leur aurai ajouté une sorte de classe annexe pour gérer leur requêtes sql personnelle.

Merci les réponses !

@PreRemove avec ton test???

Code:

---

@PreRemove avec ton test???

---

Nan nan, ce sont des méthodes callback, elles sont automatiquement appelées avant suppression, or la question qui se pose c'est une suppression conditionnelle, mais mise en place automatiquement. Même si techniquement c'était possible, tu ne penses pas que fonctionnellement le client doit être au courant de ce pourquoi la suppression peut ne pas être possible, je veux dire en d'autres termes ne faut il pas que tu contrôles programmatiquement la possibilité de suppression avec affichage de l'erreur au client si on n'a pas pu supprimer? c'est plus censé je trouve, ce genre d'opération ne doit pas passer sous silence.

Citation:

---

Nan nan, ce sont des méthodes callback, elles sont automatiquement appelées avant suppression

---

Oui et c'est justement pour ça que c'est pertinent de faire le contrôle ici et de lever une belle checked-exception si ton entité ne peut être supprimée.
Libre à toi ensuite d'en faire ce que tu veux, redirection ou autre.

Le mieux serait sans doute de faire des 'Homes' de tous les Entity, d'y faire toute la logique métier et de forcer les développeurs à utiliser ce circuit. Cela dit ça ne les empêchera peut-être pas de faire des appels directs a l'entityManager.

Code:

---

Cela dit ça ne les empêchera peut-être pas de faire des appels directs a l'entityManager.

---

Perso je suis contre le fait de faire des appels directs de l'em dans les entités, elles ne sont pas concues pour.

Code:

---

1 2	Oui et c'est justement pour ça que c'est pertinent de faire le contrôle ici et de lever une belle checked-exception si ton entité ne peut être supprimée. Libre à toi ensuite d'en faire ce que tu veux, redirection ou autre.

---

Je ne connais pas ce mécanisme, mais person je prefere avoir la main pour vérifier moi même une coherence avant suppression, pour des causes fonctionnelles, vérification établie et si j'ai droit j'utilise maintenant les primitives cascades pour suppressions transitives,c'est un avis perso.

Je suis tout à fait d'accord avec toi...

Je ne comprends absolument pas le besoin, je donne simplement une piste du comment faire.

A priori si le soft à une architecture potable:

1= Dans l'IHM ce n'est pas possible de supprimer un élément non supprimable.
2= Dans la couche de service je blinde et empêche la suppression impossible qui n'est jamais sensé être déclenchée.
3= je me contente de l'exception en DB si vraiment mes collègues développeurs font n'importe quoi et se mette à 'bypasser' la couche de service.