EnglishCommencer

La persistance des objets

Faire survivre un objet au programme : créer, lire, modifier, supprimer, états d'un objet (nouveau, géré, détaché, supprimé), DAO et dépôt, unité de travail et moment où le SQL part réellement.

  • 31 cartes
  • 5 thèmes
  • Gratuit
Réviser ce deck

Le programme, thème par thème

Le poids de chaque thème suit celui que lui donne l'examen.

  1. Notions
  2. Questions
  3. Ranger et relier
  4. Mises en situation
  5. Comprendre

Quelques cartes du deck

  • Persistance : de quoi s'agit-il ?

    Voir la réponse

    Propriété d'une donnée qui survit à l'arrêt du programme parce qu'elle est enregistrée sur un support durable, comme une base de données.

    Un objet en mémoire disparaît avec le processus. Persister un objet, c'est écrire son état dans une table pour pouvoir le reconstruire plus tard.

  • L'auteur 1 s'appelle d'abord « Hugo ». Après l'exécution de ce code JPA, quel est son nom en base ?

    ```java
    em.getTransaction().begin();
    Auteur a = em.find(Auteur.class, 1L);
    a.setNom("Zola");
    em.getTransaction().commit();
    em.close();
    `

    • Zola, sans appel à update
    • Hugo, car aucun update n'a été appelé
    • Hugo, car setNom ne modifie que la mémoire
    • une exception, car em.close() suit le commit
    Voir la réponse

    Zola, sans appel à update

    L'objet lu dans la session est géré : l'unité de travail détecte le changement et envoie UPDATE au commit. Il n'existe pas d'update explicite sur un objet géré.

  • Les opérations CRUD créer, lire, modifier et supprimer correspondent à …, …, … et ….

    Voir la réponse

    Les opérations CRUD créer, lire, modifier et supprimer correspondent à INSERT, SELECT, UPDATE et DELETE.

    Chaque opération de l'objet se traduit par une instruction SQL, que le DAO ou l'ORM produit.

  • CRUD : de quoi s'agit-il ?

    Voir la réponse

    Les quatre opérations de base sur une donnée persistante : créer (create), lire (read), modifier (update) et supprimer (delete).

    Elles correspondent aux instructions SQL INSERT, SELECT, UPDATE et DELETE.

  • Un contrôleur lit un client avec em.find, appelle client.setAdresse(nouvelle), puis l'EntityManager est fermé à la fin de la requête HTTP. Aucune erreur n'apparaît, mais l'ancienne adresse est toujours en base. Quelle est la cause ?

    • Il manque un appel explicite à update(client) juste après setAdresse
    • Aucune transaction n'a été validée, donc aucun flush n'a envoyé l'UPDATE
    • La colonne adresse est trop courte pour la nouvelle valeur
    • Le client rendu par em.find est détaché dès sa lecture
    Voir la réponse

    Aucune transaction n'a été validée, donc aucun flush n'a envoyé l'UPDATE

    L'objet lu par find est bien géré, mais ses changements ne partent qu'au flush d'une transaction, et JPA n'a pas de méthode update. Une colonne trop courte lèverait une erreur. Il faut un service qui ouvre la transaction, modifie, puis valide (commit) : c'est le rôle de la couche service, pas du contrôleur.

Réviser ce deck