JDBC et JPA

Envoyer du SQL depuis Java

JDBC est un ensemble d'interfaces du module java.sql : Connection, PreparedStatement, ResultSet… Chaque système de base de données fournit un pilote qui les implémente. Ton code ne parle qu'à JDBC ; changer de base revient surtout à changer de pilote et d'adresse.

L'adresse est une URL JDBC de la forme jdbc:sous-protocole:nom. Pour PostgreSQL : jdbc:postgresql://localhost/ecole, le port par défaut étant 5432.³ DriverManager.getConnection(url, user, mdp) ouvre une connexion ; la Javadoc indique qu'un DataSource est le moyen préféré de se connecter.¹

String url =
  "jdbc:postgresql://localhost/ecole";
String sql = "SELECT id, nom"
  + " FROM etudiants WHERE classe = ?";

try (Connection conn = DriverManager
       .getConnection(url, user, mdp);
     PreparedStatement ps =
       conn.prepareStatement(sql)) {
  ps.setString(1, "3M1");
  try (ResultSet rs = ps.executeQuery()) {
    while (rs.next()) {
      long id = rs.getLong("id");
      String nom = rs.getString("nom");
      System.out.println(id + " " + nom);
    }
  }
}

Le try (…) est un try-with-resources : chaque ressource déclarée entre ses parenthèses est fermée à la fin du bloc, même si une exception survient, dans l'ordre inverse de sa création.² Sans fermeture, une connexion garde ses ressources de base de données au lieu de les libérer tout de suite.¹ Fais défiler pour suivre ce code pas à pas.

Ne jamais coller une saisie dans du SQL

Construire une requête en collant une saisie de l'utilisateur, c'est le laisser écrire une partie de ton SQL : c'est l'injection SQL. Une requête préparée envoie le code SQL, avec ses ?, séparément des valeurs : la base distingue toujours le code des données, quoi qu'ait tapé l'utilisateur.⁴ Fais défiler.

Tout ou rien

Par défaut, une nouvelle connexion est en auto-commit : chaque requête est exécutée et validée comme une transaction à elle seule. Avec setAutoCommit(false), les requêtes sont regroupées dans une transaction qui se termine par commit(), qui rend tous les changements définitifs, ou par rollback(), qui les annule tous.¹ Fais défiler : un virement de 50 CHF qui échoue, d'abord sans transaction, puis avec.

Des objets qui deviennent des lignes

Avec JDBC, tu écris le SQL et tu recopies chaque colonne dans un objet. Un ORM automatise ce travail. En Java, la norme s'appelle Jakarta Persistence (anciennement Java Persistence API, d'où le sigle JPA). Sa version 3.2, publiée le 20 mai 2024 et intégrée à Jakarta EE 11, demande Java 17 au moins ; ses implémentations les plus connues sont Hibernate ORM et EclipseLink.⁵ Hibernate 7 implémente cette version 3.2.⁶

Une classe annotée @Entity devient une entité : chaque instance correspond à une ligne. La spécification exige un constructeur sans paramètre, public ou protégé, que l'implémentation appelle pour créer les objets.⁵ Fais défiler pour voir ce que devient chaque annotation.

Nouvelle, gérée, détachée, supprimée

On manipule les entités par un EntityManager, qui tient un contexte de persistance : l'ensemble des entités qu'il gère. La spécification distingue quatre états.⁵

Point clé : l'état des entités gérées est synchronisé avec la base au commit de la transaction.⁵ Hibernate appelle cela la vérification automatique des modifications (automatic dirty checking) : après avoir modifié une entité gérée, aucune opération explicite n'est nécessaire.⁶ Fais défiler.

Une entité détachée ne suit plus rien : la modifier ne change pas la base. Pour enregistrer ses modifications, on appelle em.merge(e), qui recopie son état sur une instance gérée de même identité, et c'est cette instance gérée que renvoie merge.⁵ Enfin, em.find(Etudiant.class, id) renvoie null si la ligne n'existe pas.

Le piège des requêtes en cascade

Une relation bidirectionnelle a un côté propriétaire : celui dont la table porte la clé étrangère. Pour un couple @ManyToOne / @OneToMany, le côté « plusieurs » doit être propriétaire, et le côté inverse le désigne avec mappedBy.⁵

@Entity
public class Classe {
  @Id @GeneratedValue
  private Long id;
  private String nom;

  @OneToMany(mappedBy = "classe")
  private List<Etudiant> etudiants =
    new ArrayList<>();
}

Par défaut, @ManyToOne se charge tout de suite (EAGER) et @OneToMany à la demande (LAZY, chargement paresseux).⁵ Le guide de Hibernate qualifie le chargement immédiat des @ManyToOne de « défaut très malheureux » de JPA et recommande de rendre presque toutes les associations paresseuses (fetch = FetchType.LAZY).⁶ Mais le paresseux a son propre piège, le problème N+1. Fais défiler.

Interroger des entités, pas des tables

JPQL (Jakarta Persistence Query Language) ressemble à SQL, mais il parle d'entités et d'attributs : Etudiant et e.classe.nom, pas etudiants et classe_id. Les paramètres nommés commencent par deux points (:nom) et, comme les ? de JDBC, ils protègent de l'injection.⁵

List<Etudiant> r = em
  .createQuery("SELECT e FROM Etudiant e"
      + " WHERE e.classe.nom = :nom"
      + " ORDER BY e.nom", Etudiant.class)
  .setParameter("nom", "3M3")
  .getResultList();

select e1_0.id, e1_0.classe_id, e1_0.nom
from etudiants e1_0
join Classe c1_0 on c1_0.id = e1_0.classe_id
where c1_0.nom = ? order by e1_0.nom

La sortie ci-dessus est le SQL réellement produit par Hibernate 7.4, mis en forme : la navigation e.classe.nom est devenue une jointure, et le paramètre un ?.

Les pièges classiques

Exercices corrigés

Cherche d'abord, puis ouvre le corrigé.

long compter(Connection conn,
             String classe)
    throws SQLException {
  String sql = "SELECT COUNT(*)"
    + " FROM etudiants WHERE classe = ?";
  try (PreparedStatement ps =
         conn.prepareStatement(sql)) {
    ps.setString(1, classe);
    try (ResultSet rs =
           ps.executeQuery()) {
      rs.next();
      return rs.getLong(1);
    }
  }
}

String sql = "SELECT * FROM etudiants"
  + " WHERE classe = ?";
try (PreparedStatement ps =
       conn.prepareStatement(sql)) {
  ps.setString(1, c);
  try (ResultSet rs = ps.executeQuery()) {
    // …
  }
}

La fiche en huit lignes

Teste-toi