Le Touilleur Express » hibernate

Jazoon day 3 : Hibernate Search

Nicolas Martignole — Thu, 25 Jun 2009 15:12:31 +0000

J’ai assisté à la présentation d’Hibernate Search par Emmanuel Bernard, après une présentation sur les Portlets 2.0 par Thomas Heute. Tous les deux de JBoss/Red Hat.

L’objectif est de nous présenter le fonctionnement d’Hibernate Search à travers des exemples de codes. Emmanuel assure la présentation avec un ordinateur de secours, son portable n’ayant pas supporté le voyage. Ouch ! Armé du package du bon speaker : un Mac + IDEA IntelliJ, il débute la présentation par une courte introduction afin de se présenter. Membre de l’équipe d’Hibernate, JCP Specification Leader de la JSR-303 « Bean Validation » et membre de l’expert group sur JPA 2.0. Il est l’auteur du livre « Hibernate Search In Action » chez Mannings. Enfin petite information, il revient vivre en France en octobre, ce qui permettra je l’espère de le voir lors des soirées des Java User Group en France.

Son objectif sera de nous expliquer en quoi consiste la recherche « full-text », ce qu’elle peut nous apporter, la magie des analyseurs, les différents algorithmes pour la recherche approximative, bref comment Hibernate Search fonctionne.

La recherche
Que ce soit un formulaire sur un site web ou autre, tôt ou tard une application souhaite offrir une fonction de recherche dans les entités d’une base de données. Hibernate Search vise à offrir une solution efficace et puissante, basée sur Lucene, afin de nous assister lors de l’écriture de cette fonctionnalité clé dans les applications.

Une recherche simple basée sur la syntaxe SQL est trop restrictive. Si vous tapez « car », comment extraire ce mot d’une colonne ? Certes il y a des requêtes comme « LIKE » mais celles-ci coûtent chères en terme de performance. Il explique que la base de données est le premier point de contention, qu’il est donc dommage de ne pas remonter cette fonction afin de la rendre plus puissante.

Par ailleurs, si vous tapez « car », est-ce que le moteur de recherche sera capable de vous montrer les entrées avec « vehicle » ? Et si vous faites une faute de frappe, est-ce que le moteur sera capable de vous monter un résultat ?

La sélection par SQL est donc très limitée.

Emmanuel enchaîne ensuite avec un argument : comment classer par pertinence les résultats ? De ces besoins est né l’idée d’Hibernate Search, offrir un moteur de recherche full-text à Hibernate.

Full Text Search
Pour répondre aux besoins exposés précédemment, la solution s’appelle « Full Text Search ». Elle est relativement simple et puissante. Le principe est de créer un Index des mots clés, en supprimant les mots de liaisons, afin d’identifier les occurences de chaque mot, et donc de créer de la pertinence. Ce principe est très performant puisque l’on ne fait pas d’accès à la base de données.

Il existe déjà différentes solutions, soit embarquées dans la base, soit dans des boîtiers externes sous la forme d’applicance, mais qui manquent de flexibilité, puisqu’en tant que développeur il sera difficile d’affiner la stratégie d’indexation.

Exemples de problèmes
Voici la mission d’Hibernate Search :
– Trouver le meilleur document, la meilleure entité selon son critère de choix.
– Classer par pertinence
– Utiliser un algorithme de similarité pour proposer à l’utilisateur des résultats similaires

Extraction
L’indexation s’effectue tout d’abord en découpant les phrases en mots, ce que l’on appelle l’extraction. A ce propos, la construction de l’index est gérée par Hibernate Search, elle s’effectue automatiquement.
L’extraction consiste tout d’abord à découper les phrases et à filtrer les mots communs pour ne garder que le sens.

Approximation
Ce système permet d’assister l’utilisateur en lui proposant des résultats très proches lorsqu’une recherche exacte ne retourne pas de résultat par exemple. Il est possible de dire à Hibernate Search que l’approximation est moins importante que la recherche exacte, de sorte que la liste des résultats ne soit pas polluée et reste pertinente. Ce poids lors de la recherche est configuré par le développeur, ce qui nous permet de régler finement le comportement du moteur. Les réponses exactes apparaissent en premier, puis les approximations.
La résolution d’approximation se fait avec des algos comme le calcul de distance Levenshtein. Tapez par exemple Hibrenate au lieu d’Hibernate, et vous verrez que le moteur détecte les résultats proches, en calculant la distance entre les lettres.

L’approche n-gram
Emmanuel présente ensuite une fonction plus avancée d’indexation, appelée n-gram. Le principe consiste à découper des mots en paquets de lettre. Par exemplte un tri-gram pour découper en paquet de 3 lettres un mot comme Hibernate donnerait : hib-ern-ate. Cela permet alors de créer des arbres d’indexation et de donner des plans de résultats encore plus pertinent.

Emmanuel montre un exemple où il tappe « poter ». les livres sur Harry Potter s’affichent, mais aussi un
« Capote » car le tri-gram « pot » a matché

Hibernate Search
je mettrai des photos en ligne un peu plus tard avec des exemples de code

Emmanuel prend ensuite l’exemple d’un Item pour nous présenter l’API.
On voit une annotation @Indexed placée sur un Entity, ce qui permet à Hibernate Search de savoir que cette entité doit être indexée. Par ailleurs il explique qu’Hibernate Search sait que lorsque l’objet est changé, il doit mettre à jour l’index Lucène. Il nous montre enfin comment configurer l’indexation afin de ne pas découper en n-gram par exemple certains champs, afin de conserver des codes ISIN.

La recherche s’effectue comme une requête HQL avec un entitymanager particulier, le FullTextEntityManager qui est une sous-classe de l’EntityManager d’Hibernate.

FullTextQuery q = entityManager.createFullTextQuery(luceneQuery, Item.class)

Pour construire sa requête Lucene, Hibernate Search laisse le soin au développeur de construire celle-ci, ce qui permet de régler finement le type de recherche. Il commence par faire une démonstration d’une recherche exacte, puis ensuite une démonstration d’une recherche avec un n-gram Analyzer.

Il est aussi possible de déclarer par exemple 2 stratégies d’indexation différentes, une indexation exacte et une indexation pour une recherche approximative. Vraiment intéressant de voir la possibilité de réglage d’Hibernate Search. La quantité d’annotations peut faire peur, mais le code est vraiment simple à lire. Quelqu’un demande d’ailleurs s’il serait possible de déclarer dans un fichier XML ce qui est déclaré ici sous forme d’Annotations.

Approximation phonetique
Il existe différents algos pour indexer de manière phonétique des mots:
- Soundex
- Metaphone (JRSKP)
- mostly for latin language
Emmanuel explique cependant que ce n’est pas le cas le plus courant dans la vraie vie.

La recherche par synonyme
L’ídée est de proposer à l’utilisateur des listes de résultats dont le domaine est proche sémantiquement, une voiture, une bagnole, un caisse si vous voulez. Pour cela il faut un dictionnaire, que l’on indexe. Cela crée de gros indexes, mais il est possible de construire des dictionnaires par référence. Dans tous les cas, il nous conseille de construire nous-mêmes nos bases de synonymes.

What’s the catch
Lucene étant relativement bas niveau, l’intégration avec un modèle, la création et la mise à jour de l’index sont donc des fonctions clés d’Hibernate Search. Celui-ci permet d’apporter facilement des fonctions de recherches très puissantes à une application. Et qui n’offrira pas finalement une fonctionnalité de recherche ?

Bonne présentation, détendue, claire, et intéressante. Et en plus avec un Mac et IDEA IntelliJ !

Hibernate : le chargement tardif c'est extra

Nicolas Martignole — Mon, 09 Mar 2009 21:42:50 +0000

Voici la suite de mon article précédent sur Hibernate et le chargement des associations.

Il existe 3 paramètres possible pour l’élément lazy lors de la définition d’une association dans une entité :
– false
– true
– extra

Le test est simple : j’édite le fichier Item.hbm.xml et j’active le chargement tardif (lazy=true). Le code Java affiche le nom de l’item chargé puis ensuite le nombre d’enchères sur l’Item en utilisant la méthode size() sur le HashSet.

Code Java

        long start = System.currentTimeMillis();
        Session session = HibernateUtil.getSessionFactory().getCurrentSession();
        session.beginTransaction();
        item1 = (Item) session.load(Item.class, new Integer(id));
        logger.info("Item name is ["+item1.getName()+"]");
        logger.info("Size of Bids Set : "+ item1.getBids().size())  ;
        logger.info("Ellapsed: " + (System.currentTimeMillis() - start));

Résultats de l’exécution

   Hibernate: /* load org.touilleur.hibernate.v1.Item */
            select item0_.ITEM_ID as ITEM1_0_0_, item0_.name as name0_0_, item0_.price as price0_0_
            from ITEM item0_ where item0_.ITEM_ID=?
INFO 2009-03-09 22:12:20,234 [Demo Hibernate] : Item name is [Item 1]
   Hibernate: /* load one-to-many org.touilleur.hibernate.v1.Item.bids */
            select bids0_.ITEM_ID as ITEM4_1_, bids0_.BID_ID as BID1_1_,
                      bids0_.BID_ID as BID1_1_0_,
                      bids0_.amount as amount1_0_, bids0_.date as date1_0_,
                      bids0_.ITEM_ID as ITEM4_1_0_
           from BID bids0_ where bids0_.ITEM_ID=?
INFO 2009-03-09 22:12:20,244 [Demo Hibernate] : Size of Bids Set : 10
INFO 2009-03-09 22:12:20,244 [Demo Hibernate] : Ellapsed: 23

On constate qu’Hibernate effectue tout d’abord une requête sur la table Item, affiche le nom de l’item puis ensuite effectue le chargement de l’ensemble des Bids en spécifiant l’id de l’Item. Je vois plusieurs soucis : le chargement de l’ensemble des colonnes de la table Bid, la deuxième requête, et finalement la requête SQL n’est pas franchement optimisée : nous voulons afficher la taille de la collection, or Hibernate charge l’ensemble des éléments…
Ce qui veut dire que 10 objets de type Bid seront créés et que la taille du hashSet de bids sera calculée en effectuant un appel à la méthode hashSet.size().
Je ne suis pas sûr d’être clair : pour retourner la taille de la collection, Hibernate charge toute la collection et retourne la taille de la liste… Vous imaginez la consommation en terme de mémoire ? Je serai presque tenté de dire qu’Hibernate n’est pas franchement écologique.

Voyons ce qu’il se passe lorsque le chargement tardif est désactivé en mettant lazy=false dans l’attribut set, dans le fichier Item.hbm.xml

INFO 2009-03-09 22:17:20,756 [Demo Hibernate] : testLazyFalse
   Hibernate: /* load org.touilleur.hibernate.v1.Item */
            select item0_.ITEM_ID as ITEM1_0_0_, item0_.name as name0_0_,
                      item0_.price as price0_0_ from ITEM item0_
            where item0_.ITEM_ID=?
   Hibernate: /* load one-to-many org.touilleur.hibernate.v1.Item.bids */
            select bids0_.ITEM_ID as ITEM4_1_, bids0_.BID_ID as BID1_1_,
                      bids0_.BID_ID as BID1_1_0_, bids0_.amount as amount1_0_,
                     bids0_.date as date1_0_, bids0_.ITEM_ID as ITEM4_1_0_
            from BID bids0_
            where bids0_.ITEM_ID=?
INFO 2009-03-09 22:17:20,777 [Demo Hibernate] : Item name is [Item 1]
INFO 2009-03-09 22:17:20,778 [Demo Hibernate] : Size of Bids Set : 10
INFO 2009-03-09 22:17:20,778 [Demo Hibernate] : Ellapsed: 21

Nous constatons que la seule différence, c’est qu’Hibernate effectue toutes les requêtes avant l’exécution du code…
Mais encore une fois, si notre code se contentait d’afficer par exemple le nombre d’enchères (ici 10) nous aurions chargé encore une fois l’arbre d’enchères pour rien. Bref pas d’optimisation en vue pour l’instant.

Voyons pour terminer ce qu’Hibernate fait lorsqe le paramètre lazy est mis à extra :

L’exécution nous donne le résultat suivant:

   Hibernate: /* load org.touilleur.hibernate.v1.Item */
          select item0_.ITEM_ID as ITEM1_0_0_, item0_.name as name0_0_,
                    item0_.price as price0_0_
          from ITEM item0_
          where item0_.ITEM_ID=?
INFO 2009-03-09 22:25:10,702 [Demo Hibernate] : Item name is [Item 1]
   Hibernate:
             select count(BID_ID) from BID where ITEM_ID =?
INFO 2009-03-09 22:25:10,707 [Demo Hibernate] : Size of Bids Set : 10
INFO 2009-03-09 22:25:10,707 [Demo Hibernate] : Ellapsed: 17

Cette fois-ci Hibernate utilise un SELECT COUNT pour calculer la taille de la collection sans la charger, ce qui est d’une part plus rapide, et d’autre part plus économique en terme de données chargées et d’instance préparées.

La valeur lazy est un moyen d’indiquer à Hibernate que l’objet Père (ici Item) contient une collection d’enfants (Bids) très grande. Si votre application calcule la taille du Set avec la méthode size() ou que vous testez par exemple si la collection est vide avec getBids().isEmpty(), Hibernate effectue une requête de type SELECT COUNT, ce qui revient donc à éviter de charger le contenu des enchères.

C’est donc une optimisation possible dans une application afin d’éviter de charger un arbre d’objet trop important dans votre code.

Si vous utilisez les annotations voici comment déclarer ce paramère :


// Code de la classe Item
@OneToMany
@org.hibernate.annoations.LazyCollection(org.hibernate.annotations.LazyCollectionOption.EXTRA)
private Set bids = new HashSet();

Voilà pour la deuxième partie, j’ai encore quelques idées que je vous proposerai dans d’autres articles prochainement.

Hibernate : gérer le chargement des associations efficacement

Nicolas Martignole — Tue, 03 Mar 2009 14:17:25 +0000

Hibernate en quelques mots

Hibernate est un moteur de mapping object-relationnel (ORM) qui permet de charger des données venant d’une base de données, vers le monde Java en réduisant la quantité de code Java à écrire.
Vous définissez une classe Java, ensuite un fichier de mapping au format XML, et Hibernate offre alors un moyen pour charger, modifier et effacer vos données. Il dispose aussi d’un cache de requête afin d’optimiser les appels et d’éviter des aller-retours inutiles avec la base de données. Un cache de second niveau offre un moyen très puissant mais délicat à maîtriser pour partager vos données et réduire le coût de la base de données dans une application.
Il est possible d’utiliser soit des annotations sur la classe Java, soit des fichiers XML. Sachez que si vous utilisez des annotations, un fichier de configuration XML peut vous permettre de surcharger le mapping des annotations, et donc d’éviter d’être bloqué par du code déjà compilé sur lequel vous n’avez pas le contrôle.

Objectifs de l’article

La première partie de l’article est assez dictatique pour ceux qui ne connaissent pas Hibernate 3. La seconde partie sera plus intéressante pour les utilisateurs qui souhaitent voir quelques options avancées d’Hibernate. Nous verrons comment gérer efficacement les relations entre les objets, les stratégies de chargement et les différentes types d’option de chargement tardif (Lazy instanciation).

Code source de l’article

Pour les besoins de cet article j’ai préparé un projet simple avec maven2, que vous pouvez télécharger en fin d’article. Le code est distribué sous licence Creatives Commons v2 avec quelques restrictions sur la non modification et l’interdiction d’utiliser le code à des fins commerciales sans mon accord.

Si vous souhaitez tester quelques fonctionnalités en lisant l’article, vous aurez besoin de Java 5 et de Maven 2.0.6 minimum pour compiler et tester le code. J’utilise un test unitaire JUnit 3.8 simple pour lancer les différents tests, un simple « mvn test » en ligne de commande vous permet de compiler le code et de lancer la base de données embarquée HSQLDB.

Un peu de relationnel

J’ai repris un exemple simple pour passer en revue quelques caractéristiques d’Hibernate plus ou moins connues.
Prenons tout d’abord la classe Item, correspondant à un article.
Un Item est caractérisé par son nom, son prix et une clé d’identité. Un constructeur vide sans argument est requis pour qu’Hibernate puisse décorer cette classe avec un proxy avec la librairie CGLIB, sans quoi une exception org.hibernate.InstantiationException sera levée par Hibernate. De même il est recommandé de ne pas déclarer de classe finale comme entité si vous souhaitez qu’Hibernate puisse utiliser un proxy. Si malgré tout vous êtes obligés de déclarer une méthode finale, il faudra alors désactiver le chargement tardif (lazy=false) dans la configuration de l’entité [1]

public class Item {
    private Integer id;
    private String name;
    private float price;
    private Set bids=new HashSet();

    public Item() {

    }

    public Item(String name, float price){
        //...
    }
     // Getter, setter, equals, hashCode et toString
}

La classe Bid (enchère en anglais) est une offre émise par un acheteur sur notre Item. Les attributs sont l’heure de l’enchère et son montant.

public class Bid {
    private Integer id;
    private float amount;
    private Date date;
    private Item item;

    public Bid(){
    }

    // getter, setter, hashCode, equals
}

Le fichier de mapping Hibernate Item.hbm.xml permet à Hibernate d’effectuer le mapping entre la classe Item et notre base de données. La relation un-vers-plusieurs (un Item contient plusieurs Bids) est définie avec un set. Nous utiliserons une table de jointure ITEM_BIDS, le chargement tardif sera désactivé (lazy=false), nous indiquons à Hibernate que la relation inverse est déclarée dans Bid (inverse=true).

Hibernate recommande d’utiliser des associations symétriques. Dans notre application, une enchère sans article n’a pas de sens. Nous configurons donc notre association many-to-one avec l’attribut not-null à true dans le fichier Bid.hbm.xml:

Stratégie de chargement de l’association

Hibernate évite au maximum de faire appel à la base de données, et tend à limiter le nombre de requête, afin d’alléger le traitement. Par défaut la stratégie de chargement tardive qui permet d’optimiser les performances, peut provoquer quelques moments difficile lorsque surgit l’exception LazyInitializationException.

Une exception de type LazyInitializationException sera renvoyée par Hibernate si une collection ou un proxy non initialisé est accédé en dehors de la portée de la Session, e.g. lorsque l’entité à laquelle appartient la collection ou qui a une référence vers le proxy est dans l’état « détachée ».

Cela se produit dans les architectures 3-tiers, où le tiers de présentation Web est séparé physiquement de l’ejbtiers pour des raisons de sécurité. Ce type d’architecture soufre de plusieurs soucis : si vous interdisez l’accès à la base de données à partir du web-tiers, il faudra donc que la stratégie de chargement tardive d’Hibernate soit désactivée (lazy=false). Dans le cas où nous souhaitons charger un Item, toutes les enchères associées seront alors chargées. Imaginez que pour seulement afficher le nom de l’Item, nous allons aussi charger 1500 Bids par exemple…
Il est alors important de configurer Hibernate finement et d’utiliser des jointures afin d’éviter trop de requêtes.

Dans un premier temps, nous allons regarder les différentes possibilités de chargement d’une association, en essayant différentes valeurs pour l’attribut fetch de l’attribut set. La valeur par défaut lorsqu’elle n’est pas précisée est « select ». Les 3 valeurs possibles sont select, join et subselect. Nous désactivons le chargement tardif en ajoutant le mot clé « lazy=false » dans le fichier Item.hbm.xml.

Fetch strategy par défaut en mode lazy=false

Pour ce test, dans le test unitaire SelectTest, nous allons voir comment il est possible de changer la stratégie de chargement directement dans le code. Avant cela, regardons comment travaille Hibernate par défaut avant de tester d’autres modes de chargement. Par défault lorsque FetchMode est à DEFAULT comme ci-dessous, Hibernate se repose sur ce que vous avez déclaré dans votre fichier de mapping, Item.hbm.xml pour nous.

// voir org.touilleur.hibernate.SelectTest
 Item item1 = (Item) session.createCriteria(Item.class)
                .setFetchMode("bids", FetchMode.DEFAULT)
                .add(Restrictions.idEq(id))
                .uniqueResult();

La configuration du chargement de l’association s’effectue dans le fichier de configuration hibernate.cfg.xml à l’aide de l’attribut fetch. La valeur par défaut est select, les 2 autres valeurs possibles sont join et subselect. Voyons d’abord par défaut le comportement d’Hibernate :

       fetch="select" cascade="all">

Pour continuer, exécutez la méthode testSelectOneItemWithDefault.
La console affiche les requêtes SQL suivantes:
... INFO 2009-02-27 22:24:21,788 [Demo Hibernate] : Starting selectOneItemWithDefault Hibernate: /* criteria query */ select this_.ITEM_ID as ITEM1_0_0_, this_.name as name0_0_, this_.price as price0_0_ from ITEM this_ where this_.ITEM_ID = ? Hibernate: /* load one-to-many org.touilleur.hibernate.v1.Item.bids */ select bids0_.ITEM_ID as ITEM4_1_, bids0_.BID_ID as BID1_1_, bids0_.BID_ID as BID1_1_0_, bids0_.amount as amount1_0_, bids0_.date as date1_0_, bids0_.ITEM_ID as ITEM4_1_0_ from BID bids0_ where bids0_.ITEM_ID=? INFO 2009-02-27 22:24:21,791 [Demo Hibernate] : Loaded item1 with a FetchMode set to DEFAULT...

2 requêtes sont nécessaires pour effectuer le chargement de l’unique Item.

Chargement de l’ensemble des Items

Le test unitaire testSelecTAllItemsWithDefaultFetchMode sélectionne les 2 Items de notre base et affiche ensuite les 2 items. La méthode toString de la class Item force le chargement de la liste des enchères. Nous avons désactivé le chargement tardif (lazy=false) et il est donc normal de voir Hibernate charger les Bids.

Que se passe-t-il lorsque nous exécutons ce code ?
INFO 2009-03-03 10:18:30,670 [Demo Hibernate] : testSelecTAllItemsWithDefaultFetchMode - begin Hibernate: /* criteria query */ select this_.ITEM_ID as ITEM1_0_0_, this_.name as name0_0_, this_.price as price0_0_ from ITEM this_ Hibernate: /* load one-to-many org.touilleur.hibernate.v1.Item.bids */ select bids0_.ITEM_ID as ITEM4_1_, bids0_.BID_ID as BID1_1_, bids0_.BID_ID as BID1_1_0_, bids0_.amount as amount1_0_, bids0_.date as date1_0_, bids0_.ITEM_ID as ITEM4_1_0_ from BID bids0_ where bids0_.ITEM_ID=? Hibernate: /* load one-to-many org.touilleur.hibernate.v1.Item.bids */ select bids0_.ITEM_ID as ITEM4_1_, bids0_.BID_ID as BID1_1_, bids0_.BID_ID as BID1_1_0_, bids0_.amount as amount1_0_, bids0_.date as date1_0_, bids0_.ITEM_ID as ITEM4_1_0_ from BID bids0_ where bids0_.ITEM_ID=? INFO 2009-03-03 10:18:30,704 [Demo Hibernate] : Item #1 : Item{id=1, bids=[Bid{id=7, amount=107.0, date=2009-03-03 10:18:30.637}, Bid{id=10, amount=110.0, date=2009-03-03 10:18:30.643}, Bid{id=6, amount=106.0, date=2009-03-03 10:18:30.632}, Bid{id=8, amount=108.0, date=2009-03-03 10:18:30.638}, Bid{id=2, amount=102.0, date=2009-03-03 10:18:30.626}, Bid{id=4, amount=104.0, date=2009-03-03 10:18:30.629}, Bid{id=1, amount=101.0, date=2009-03-03 10:18:30.625}, Bid{id=9, amount=109.0, date=2009-03-03 10:18:30.639}, Bid{id=5, amount=105.0, date=2009-03-03 10:18:30.63}, Bid{id=3, amount=103.0, date=2009-03-03 10:18:30.628}], name='TV LCD', price=340.0} INFO 2009-03-03 10:18:30,706 [Demo Hibernate] : Item #2 : Item{id=2, bids=[Bid{id=20, amount=144.0, date=2009-03-03 10:18:30.657}, Bid{id=15, amount=125.0, date=2009-03-03 10:18:30.651}, Bid{id=13, amount=43.0, date=2009-03-03 10:18:30.647}, Bid{id=16, amount=116.0, date=2009-03-03 10:18:30.652}, Bid{id=14, amount=84.0, date=2009-03-03 10:18:30.648}, Bid{id=11, amount=10.0, date=2009-03-03 10:18:30.645}, Bid{id=17, amount=137.0, date=2009-03-03 10:18:30.654}, Bid{id=19, amount=139.0, date=2009-03-03 10:18:30.656}, Bid{id=12, amount=22.0, date=2009-03-03 10:18:30.646}, Bid{id=18, amount=138.0, date=2009-03-03 10:18:30.655}], name='Plasma', price=1230.0} INFO 2009-03-03 10:18:30,709 [Demo Hibernate] : testSelecTAllItemsWithDefaultFetchMode - end


Hibernate utilise 3 requêtes pour effectuer le chargement. C'est un problème important. Imaginez que votre base contient 1000 items qui eux-mêmes référencent 10 Bids différents... Nous n'optimisons pas vraiment notre chargement, cela nous coûte cher en nombre de requêtes SQL. De plus, n'étant pas en mode de chargement tardif, nous voyons bien qu'Hibernate effectue les 3 requêtes avant d'attaquer l'affichage de notre résultat.
Que se passe-t-il lorsque le mode lazy est actif ?

Rappelons que par défaut Hibernate étant bien fait, ce mode est implicite et il est le mode de fonctionnement par défaut d'Hibernate. Pour ce test, je me contente de changer dans le fichier Item.hbm.xml la configuration du chargement tardif et je relance le même test afin de voir comment Hibernate charge la collection:


    
        
            
        
        
        
        
 <-- LAZY est à TRUE -->

Je relance le même test unitaire :INFO 2009-03-03 10:26:38,910 [Demo Hibernate] : testSelecTAllItemsWithDefaultFetchMode - begin Hibernate: /* criteria query */ select this_.ITEM_ID as ITEM1_0_0_, this_.name as name0_0_, this_.price as price0_0_ from ITEM this_ Hibernate: /* load one-to-many org.touilleur.hibernate.v1.Item.bids */ select bids0_.ITEM_ID as ITEM4_1_, bids0_.BID_ID as BID1_1_, bids0_.BID_ID as BID1_1_0_, bids0_.amount as amount1_0_, bids0_.date as date1_0_, bids0_.ITEM_ID as ITEM4_1_0_ from BID bids0_ where bids0_.ITEM_ID=? INFO 2009-03-03 10:26:38,937 [Demo Hibernate] : Item #1 : Item{id=1, bids=[Bid{id=1, amount=101.0, date=2009-03-03 10:26:38.864}, Bid{id=10, amount=110.0, date=2009-03-03 10:26:38.883}, Bid{id=8, amount=108.0, date=2009-03-03 10:26:38.878}, Bid{id=3, amount=103.0, date=2009-03-03 10:26:38.867}, Bid{id=6, amount=106.0, date=2009-03-03 10:26:38.871}, Bid{id=2, amount=102.0, date=2009-03-03 10:26:38.866}, Bid{id=9, amount=109.0, date=2009-03-03 10:26:38.879}, Bid{id=5, amount=105.0, date=2009-03-03 10:26:38.87}, Bid{id=7, amount=107.0, date=2009-03-03 10:26:38.876}, Bid{id=4, amount=104.0, date=2009-03-03 10:26:38.868}], name='TV LCD', price=340.0} Hibernate: /* load one-to-many org.touilleur.hibernate.v1.Item.bids */ select bids0_.ITEM_ID as ITEM4_1_, bids0_.BID_ID as BID1_1_, bids0_.BID_ID as BID1_1_0_, bids0_.amount as amount1_0_, bids0_.date as date1_0_, bids0_.ITEM_ID as ITEM4_1_0_ from BID bids0_ where bids0_.ITEM_ID=? INFO 2009-03-03 10:26:38,944 [Demo Hibernate] : Item #2 : Item{id=2, bids=[Bid{id=18, amount=138.0, date=2009-03-03 10:26:38.896}, Bid{id=11, amount=10.0, date=2009-03-03 10:26:38.885}, Bid{id=20, amount=144.0, date=2009-03-03 10:26:38.898}, Bid{id=16, amount=116.0, date=2009-03-03 10:26:38.893}, Bid{id=14, amount=84.0, date=2009-03-03 10:26:38.888}, Bid{id=19, amount=139.0, date=2009-03-03 10:26:38.897}, Bid{id=15, amount=125.0, date=2009-03-03 10:26:38.892}, Bid{id=12, amount=22.0, date=2009-03-03 10:26:38.886}, Bid{id=13, amount=43.0, date=2009-03-03 10:26:38.887}, Bid{id=17, amount=137.0, date=2009-03-03 10:26:38.895}], name='Plasma', price=1230.0} INFO 2009-03-03 10:26:38,947 [Demo Hibernate] : testSelecTAllItemsWithDefaultFetchMode - end

Cette fois-ci nous constatons qu’Hibernate effectue une requête que lorsque cela devient nécessaire, ce qui est adapté dans la majorité des cas.
Lorsque le mode lazy est désactivé, Hibernate effectue n+1 requêtes sans jointure. Cela peut entraîner un très grand nombre de requêtes vers la base. Nous allons donc voir comment optimiser dans ce cas précis le chargement des associations.

Fetch strategy à join et lazy=false

Si nous ne pouvons pas utiliser le chargement tardif, il est alors intéressant d’utiliser une requête et d’effectuer une jointure entre la table Item et la table Bid. Pour cela il suffit de changer de stratégie lors de la requête. Nous passons maintenant le mode de récupération (FetchMode) à JOIN :

// voir la class org.touilleur.hibernate.SelectTest
 Item item1 = (Item) session.createCriteria(Item.class)
                .setFetchMode("bids", FetchMode.JOIN)
                .add(Restrictions.idEq(id))
                .uniqueResult();

Si vous savez qu’il sera toujours plus intéresant d’utiliser une requête par jointure vous pouvez aussi changer la stratégie dans le fichier Item.hbm.xml :
fetch="join" cascade="all">

Le test selectOneItemWithJoin nous montre alors qu’une seule requête est exécutée, et qu’une jointure externe gauche entre la table Item et la table Bid permet de retrouver un Item avec 0 ou plusieurs Bid.

INFO 2009-02-27 22:24:21,772 [Demo Hibernate] : Starting selectOneItemWithJoin Hibernate: /* criteria query */ select this_.ITEM_ID as ITEM1_0_1_, this_.name as name0_1_, this_.price as price0_1_, bids2_.ITEM_ID as ITEM4_3_, bids2_.BID_ID as BID1_3_, bids2_.BID_ID as BID1_1_0_, bids2_.amount as amount1_0_, bids2_.date as date1_0_, bids2_.ITEM_ID as ITEM4_1_0_ from ITEM this_ left outer join BID bids2_ on this_.ITEM_ID=bids2_.ITEM_ID where this_.ITEM_ID = ? INFO 2009-02-27 22:24:21,775 [Demo Hibernate] : Loaded item1 with a FetchMode set to JOIN
Notez qu’Hibernate utilise une jointure externe de la table Item vers la table Bid, cela nous donne alors en simplifiant le code SQL la requête suivante :
select i.*,b* from ITEM i outer join BID b on i.ITEM_ID=b.ITEM_ID
Par défaut il n’y a donc pas de critères de distinction, et nous nous retrouvons alors avec 20 résultats, ce qui sera pratique pour remplir un tableau mais qui n’est pas forcément souhaitable pour votre code.

INFO 2009-03-03 10:30:53,041 [Demo Hibernate] : testSelecTAllItemsWithJoinFetchMode - begin Hibernate: /* criteria query */ select this_.ITEM_ID as ITEM1_0_1_, this_.name as name0_1_, this_.price as price0_1_, bids2_.ITEM_ID as ITEM4_3_, bids2_.BID_ID as BID1_3_, bids2_.BID_ID as BID1_1_0_, bids2_.amount as amount1_0_, bids2_.date as date1_0_, bids2_.ITEM_ID as ITEM4_1_0_ from ITEM this_ left outer join BID bids2_ on this_.ITEM_ID=bids2_.ITEM_ID INFO 2009-03-03 10:30:53,072 [Demo Hibernate] : Item #1 : Item{id=1, bids=[Bid{id=3, amount=103.0, date=2009-03-03 10:30:52.999}, Bid{id=8, amount=108.0, date=2009-03-03 10:30:53.01}, Bid{id=6, amount=106.0, date=2009-03-03 10:30:53.003}, Bid{id=10, amount=110.0, date=2009-03-03 10:30:53.014}, Bid{id=5, amount=105.0, date=2009-03-03 10:30:53.002}, Bid{id=2, amount=102.0, date=2009-03-03 10:30:52.998}, Bid{id=7, amount=107.0, date=2009-03-03 10:30:53.009}, Bid{id=4, amount=104.0, date=2009-03-03 10:30:53.001}, Bid{id=9, amount=109.0, date=2009-03-03 10:30:53.011}, Bid{id=1, amount=101.0, date=2009-03-03 10:30:52.997}], name='TV LCD', price=340.0} INFO 2009-03-03 10:30:53,074 [Demo Hibernate] : Item #1 : Item{id=1, bids=[Bid{id=3, amount=103.0, date=2009-03-03 10:30:52.999}, Bid{id=8, amount=108.0, date=2009-03-03 10:30:53.01}, Bid{id=6, amount=106.0, date=2009-03-03 10:30:53.003}, Bid{id=10, amount=110.0, date=2009-03-03 10:30:53.014}, Bid{id=5, amount=105.0, date=2009-03-03 10:30:53.002}, Bid{id=2, amount=102.0, date=2009-03-03 10:30:52.998}, Bid{id=7, amount=107.0, date=2009-03-03 10:30:53.009}, Bid{id=4, amount=104.0, date=2009-03-03 10:30:53.001}, Bid{id=9, amount=109.0, date=2009-03-03 10:30:53.011}, Bid{id=1, amount=101.0, date=2009-03-03 10:30:52.997}], name='TV LCD', price=340.0} ... Message répété 20 fois ... INFO 2009-03-03 10:30:53,125 [Demo Hibernate] : testSelecTAllItemsWithJoinFetchMode - end
Pour ajouter une clause DISTINCT, nous pouvons modifier notre critère et utiliser un ResultTransformer :

List l = session.createCriteria(Item.class)
                .setFetchMode("bids", FetchMode.JOIN)
                .setResultTransformer(Criteria.DISTINCT_ROOT_ENTITY)
                .list();

En exécutant à nouveau notre test voici le résultat :
INFO 2009-03-03 10:43:31,196 [Demo Hibernate] : testSelecTAllItemsWithJoinFetchMode - begin Hibernate: /* criteria query */ select this_.ITEM_ID as ITEM1_0_1_, this_.name as name0_1_, this_.price as price0_1_, bids2_.ITEM_ID as ITEM4_3_, bids2_.BID_ID as BID1_3_, bids2_.BID_ID as BID1_1_0_, bids2_.amount as amount1_0_, bids2_.date as date1_0_, bids2_.ITEM_ID as ITEM4_1_0_ from ITEM this_ left outer join BID bids2_ on this_.ITEM_ID=bids2_.ITEM_ID INFO 2009-03-03 10:43:31,229 [Demo Hibernate] : Item #1 : Item{id=1, bids=[Bid{id=8, amount=108.0, date=2009-03-03 10:43:31.162}, Bid{id=7, amount=107.0, date=2009-03-03 10:43:31.16}, Bid{id=2, amount=102.0, date=2009-03-03 10:43:31.149}, Bid{id=6, amount=106.0, date=2009-03-03 10:43:31.154}, Bid{id=10, amount=110.0, date=2009-03-03 10:43:31.167}, Bid{id=9, amount=109.0, date=2009-03-03 10:43:31.163}, Bid{id=3, amount=103.0, date=2009-03-03 10:43:31.15}, Bid{id=5, amount=105.0, date=2009-03-03 10:43:31.153}, Bid{id=1, amount=101.0, date=2009-03-03 10:43:31.147}, Bid{id=4, amount=104.0, date=2009-03-03 10:43:31.151}], name='TV LCD', price=340.0} INFO 2009-03-03 10:43:31,232 [Demo Hibernate] : Item #2 : Item{id=2, bids=[Bid{id=19, amount=139.0, date=2009-03-03 10:43:31.181}, Bid{id=17, amount=137.0, date=2009-03-03 10:43:31.179}, Bid{id=15, amount=125.0, date=2009-03-03 10:43:31.176}, Bid{id=13, amount=43.0, date=2009-03-03 10:43:31.171}, Bid{id=11, amount=10.0, date=2009-03-03 10:43:31.169}, Bid{id=12, amount=22.0, date=2009-03-03 10:43:31.17}, Bid{id=14, amount=84.0, date=2009-03-03 10:43:31.172}, Bid{id=20, amount=144.0, date=2009-03-03 10:43:31.182}, Bid{id=18, amount=138.0, date=2009-03-03 10:43:31.18}, Bid{id=16, amount=116.0, date=2009-03-03 10:43:31.177}], name='Plasma', price=1230.0} INFO 2009-03-03 10:43:31,235 [Demo Hibernate] : testSelecTAllItemsWithJoinFetchMode - end

Voir la FAQ Hibernate [Hibernate does not return distinct results for a query with outer join fetching enabled for a collection (even if I use the distinct keyword)]

La sélection par jointure est donc une option possible. Nous sommes passés de 3 requêtes à une seule requête, ce qui est une optimisation permettant de réduire le nombre de requête SQL. Encore une fois, c’est à vous et à votre DBA de décider de la meilleur stratégie, il ne faut donc pas appliquer à l’aveugle les paramètres. Les jointures sont efficaces si vos colonnes de jointure sont correctement indexées, il est donc important de s’assurer que votre administrateur de base de données a aussi validé vos changements.

Fetch mode par subselect

Hibernate propose un mode de sélection moins connu et pourtant très efficace sur les associations, le mode subselect. L’idée est simplement d’utiliser le résultat d’une première requête comme critère de la sélection de la deuxième requête pour effectuer une requête plus efficace.

Ce que nous avons vu en premier, en mode lazy=false et fetch=select, c’est qu’Hibernate effectue n+1 requêtes pour charger la liste des Bids pour chacun des Items.

/* Retrouve la liste des Items */
select * from ITEM

/* Retrouve la list des Bids pour chaque Item */
select * from BID  where ITEM_ID = 12
select * from BID  where ITEM_ID = 34
select * from BID  where ITEM_ID = 37
select * from BID  where ITEM_ID = 39

Il y deux façons d’optimiser ce type de requête : soit utiliser le paramètre batch-size dans l’element set du fichier Item.hbm.xml, soit utiliser une requête de sous sélection. Je ne sais pas si ce mode est supporté par toutes les bases de données, mais voici le principe :
- Sélectionner les Items
- Sélectionner les Bids en utilisant les ID des items précedemment trouvé

/* Retrouve la liste des Items */
select * from ITEM

/* Retrouve la list des Bids pour chaque Item */
select * from BID  where ITEM_ID IN( 12, 34, 37, 39)

Pour cela il n’est pas possible de changer le mode de sélection dans le code, il faut éditer le fichier Item.hbm.xml et préciser que le fetch type est subselect

Après avoir édité le fichier Item.hbm.xml, le test unitaire testSelecTAllItemsWithSubSelectFetchMode nous montre que deux requêtes sont exécutées au lieu de n+1 dans le cas du mode « select » ou une seule requête dans le cas du mode « join » :
INFO 2009-03-03 11:06:36,678 [Demo Hibernate] : testSelecTAllItemsWithSubSelectFetchMode - begin Hibernate: /* criteria query */ select this_.ITEM_ID as ITEM1_0_0_, this_.name as name0_0_, this_.price as price0_0_ from ITEM this_ Hibernate: /* load one-to-many org.touilleur.hibernate.v1.Item.bids */ select bids0_.ITEM_ID as ITEM4_1_, bids0_.BID_ID as BID1_1_, bids0_.BID_ID as BID1_1_0_, bids0_.amount as amount1_0_, bids0_.date as date1_0_, bids0_.ITEM_ID as ITEM4_1_0_ from BID bids0_ where bids0_.ITEM_ID in (select this_.ITEM_ID from ITEM this_) INFO 2009-03-03 11:06:36,711 [Demo Hibernate] : Item #1 : Item{id=1, bids=[Bid{id=7, amount=107.0, date=2009-03-03 11:06:36.646}, Bid{id=3, amount=103.0, date=2009-03-03 11:06:36.636}, Bid{id=8, amount=108.0, date=2009-03-03 11:06:36.647}, Bid{id=2, amount=102.0, date=2009-03-03 11:06:36.635}, Bid{id=6, amount=106.0, date=2009-03-03 11:06:36.64}, Bid{id=5, amount=105.0, date=2009-03-03 11:06:36.639}, Bid{id=1, amount=101.0, date=2009-03-03 11:06:36.633}, Bid{id=9, amount=109.0, date=2009-03-03 11:06:36.648}, Bid{id=4, amount=104.0, date=2009-03-03 11:06:36.637}, Bid{id=10, amount=110.0, date=2009-03-03 11:06:36.652}], name='TV LCD', price=340.0} INFO 2009-03-03 11:06:36,714 [Demo Hibernate] : Item #2 : Item{id=2, bids=[Bid{id=14, amount=84.0, date=2009-03-03 11:06:36.657}, Bid{id=18, amount=138.0, date=2009-03-03 11:06:36.664}, Bid{id=17, amount=137.0, date=2009-03-03 11:06:36.663}, Bid{id=20, amount=144.0, date=2009-03-03 11:06:36.666}, Bid{id=15, amount=125.0, date=2009-03-03 11:06:36.66}, Bid{id=12, amount=22.0, date=2009-03-03 11:06:36.655}, Bid{id=13, amount=43.0, date=2009-03-03 11:06:36.656}, Bid{id=19, amount=139.0, date=2009-03-03 11:06:36.665}, Bid{id=16, amount=116.0, date=2009-03-03 11:06:36.661}, Bid{id=11, amount=10.0, date=2009-03-03 11:06:36.654}], name='Plasma', price=1230.0} INFO 2009-03-03 11:06:36,716 [Demo Hibernate] : testSelecTAllItemsWithSubSelectFetchMode - end

L’intérêt de ce mode de sélection est de récuperer en deux requêtes l’ensemble des Items et ensuite des Bids. Si vous faites enfin le test en mode « lazy=true » vous verrez par ailleurs qu’Hibernate n’effectue pas de chargement tardif mais qu’il charge toutes les données. Le mode de sélection en « SUBSELECT » limite à deux requêtes le nombre d’interrogation nécessaire, le tout sans jointure. C’est donc une option intéressante à tester selon la logique de votre application.

Fetch mode par batch size

La 4ème technique pour améliorer les chargements par lot est d’activer l’option batch-size. Afin de montrer son fonctionnement nous allons d’abord limiter la taille de chargement à 1 pour le nombre d’Item et le nombre de collection de Bid :

Nous voyons qu’à l’exécution, Hibernate effectue une requete pour récuperer une liste de deux Items puis ensuite deux requêtes pour chacun des Items. En mode lazy, nous aurions simplement vu que la deuxième requête de chargement aurait été effectuée plus tardivement

INFO 2009-03-03 13:19:19,261 [Demo Hibernate] : testSelecTAllItemsWithSubSelectFetchMode - begin Hibernate: /* criteria query */ select this_.ITEM_ID as ITEM1_0_0_, this_.name as name0_0_, this_.price as price0_0_ from ITEM this_ Hibernate: /* load one-to-many org.touilleur.hibernate.v1.Item.bids */ select bids0_.ITEM_ID as ITEM4_1_, bids0_.BID_ID as BID1_1_, bids0_.BID_ID as BID1_1_0_, bids0_.amount as amount1_0_, bids0_.date as date1_0_, bids0_.ITEM_ID as ITEM4_1_0_ from BID bids0_ where bids0_.ITEM_ID=? Hibernate: /* load one-to-many org.touilleur.hibernate.v1.Item.bids */ select bids0_.ITEM_ID as ITEM4_1_, bids0_.BID_ID as BID1_1_, bids0_.BID_ID as BID1_1_0_, bids0_.amount as amount1_0_, bids0_.date as date1_0_, bids0_.ITEM_ID as ITEM4_1_0_ from BID bids0_ where bids0_.ITEM_ID=? INFO 2009-03-03 13:19:19,294 [Demo Hibernate] : Item #1 : Item{id=1, bids=[Bid{id=2, amount=102.0, date=2009-03-03 13:19:19.217}, Bid{id=5, amount=105.0, date=2009-03-03 13:19:19.221}, Bid{id=3, amount=103.0, date=2009-03-03 13:19:19.218}, Bid{id=10, amount=110.0, date=2009-03-03 13:19:19.233}, Bid{id=7, amount=107.0, date=2009-03-03 13:19:19.227}, Bid{id=4, amount=104.0, date=2009-03-03 13:19:19.219}, Bid{id=1, amount=101.0, date=2009-03-03 13:19:19.215}, Bid{id=9, amount=109.0, date=2009-03-03 13:19:19.23}, Bid{id=8, amount=108.0, date=2009-03-03 13:19:19.229}, Bid{id=6, amount=106.0, date=2009-03-03 13:19:19.222}], name='TV LCD', price=340.0} INFO 2009-03-03 13:19:19,297 [Demo Hibernate] : Item #2 : Item{id=2, bids=[Bid{id=19, amount=139.0, date=2009-03-03 13:19:19.247}, Bid{id=16, amount=116.0, date=2009-03-03 13:19:19.243}, Bid{id=11, amount=10.0, date=2009-03-03 13:19:19.236}, Bid{id=18, amount=138.0, date=2009-03-03 13:19:19.246}, Bid{id=13, amount=43.0, date=2009-03-03 13:19:19.237}, Bid{id=20, amount=144.0, date=2009-03-03 13:19:19.248}, Bid{id=14, amount=84.0, date=2009-03-03 13:19:19.238}, Bid{id=15, amount=125.0, date=2009-03-03 13:19:19.242}, Bid{id=17, amount=137.0, date=2009-03-03 13:19:19.245}, Bid{id=12, amount=22.0, date=2009-03-03 13:19:19.236}], name='Plasma', price=1230.0} INFO 2009-03-03 13:19:19,300 [Demo Hibernate] : testSelecTAllItemsWithSubSelectFetchMode - end

Le chargement par lot est une technique efficace qui permet de précharger un nombre défini de proxy non initialisé si un premier proxy est accedé. Il y a donc l’optimisation au niveau du chargement de l’entité (Item) et l’optimisation au niveau du chargement de la collection (Bid).

Le chargement par lot pour notre classe Item fonctionne de la manière suivante : dans votre base imaginons que nous ayons 10 Items, chacun de ces Items référencent un Acheteur avec une relation un-à-un. La relation est mappée avec un proxy en mode lazy= »true ». Si par défaut vous chargez la liste des Items puis qu’ensuite vous appelez la méthode getBuyer() pour retrouver l’acheteur, Hibernate effectuera alors 10 requêtes SQL (10 items).
Le chargement par lot permet de spécifier à Hibernate la taille d’une fenêtre de chargement, en utilisant les clés primaires ou les clés étrangères, qui ici seraient dans la table BUYER.

...
Hibernate exécutera non plus 10 requêtes SQL mais une seule pour charger l’ensemble des acheteurs. Idéalement vous l’aurez deviné, ce batch-size correspond au nombre d’éléments affichés sur une page Web, dans un tableau paginé par exemple.

Ensuite il est possible d’activer le chargement par lot sur les collections. Notre Item a une collection de Bid. Imaginons que je charge mes 10 Items dans ma Session Hibernate. Par défaut, chaque appel à getBids() entrainera alors une requête SQL, soit 10 requêtes pour charger chacune des collections. En spécifiant une taille de batch comme ci-dessous il est possible d’optimiser le nombre d’éléments préchargés et donc de réduire le nombre de requête SQL :

...

Pour 7 enchères, Hibernate chargera alors 3,3,1 en effectuant 3 requêtes au lieu de 7 requêtes par exemple. Cela permet de réduire encore une fois le nombre de requête, et cette valeur doit être guidée par le code de votre application et l’usage que vous en faîtes.
Pour cette raison il est souvent plus souhaitable de définir la taille du batch au niveau du code comme dans ci-dessous:

 List l = session.createCriteria(Item.class)
                    .setFetchSize(10)
                    .list();

Petite astuce au passage : si vous souhaitez limiter le nombre de résultat retourné, vous connaissez sans doute la commande setMaxResults(int i).

List l = session.createCriteria(Item.class)
                    .setMaxResults(10)
                    .list();

Par curiosité je me suis un peu demandé pourquoi Hibernate prend plus de temps que la même requête SQL exécutée sur ma base de test. En fouillant un peu je me suis aperçu qu’il est intéressant de préciser la taille du batch afin de ne récuperer qu’un seul lot :

List l = session.createCriteria(Item.class)
                    .setMaxResults(10)
                    .setFetchSize(10)
                    .list();

Essayez sur votre code vous verrez la différence.

Conclusion de la première partie

Lorsque le chargement tardif ne peut pas être utilisé, il est important de vérifier que la stratégie par défaut d’Hibernate n’entraine pas un nombre de requêtes SQL trop importantes. Il est possible de limiter ce nombre en utilisant des jointures ou des selections imbriquées. A vous ensuite d’optimiser vos réglages selon votre application.

Dans la deuxième partie nous allons voir les 3 paramètres différents de chargement des collections.

J’espère que vous aurez apprécié. Si vous voulez aller un peu plus loin, il ne vous reste plus qu’à télécharger le code de l’article et à commencer à tester les différentes configurations possibles d’Hibernate. Pour les personnes à la recherche d’un tutorial sur Hibernate, la première partie vous montre un exemple simple de mapping pour commencer à apprendre Hibernate.

Bonne lecture et à bientôt pour la deuxième partie !

Code source de l’article
ArticleTouilleur_hibernate.tar.gz