[hibernate 3.1] Les techniques de chargement ("lazy loading")

Version imprimable

Bonjour.

J'ai lu beaucoup de documentation sur Hibernate, et notamment sur les diverses technique de chargement ou également appellé "lazy loading".

J'ai pu lire beaucoup de chose sur les propriétés "lazy", "outer-join", "fecth" ou encore "batch-size" mais là où ca bloque, c'est que je n'ai pas réellement comment et à quel moment utiliser tout celà. Ma question est donc plus sur un principe d'utilisation. J'aimerais si possible que l'on me guide dans le mapping d'un exemple. J'aimerais mapper une base qui associe un fichier à plusieurs messages. A première vue j'ai réalisé un mapping de ce style (les propriétés sont là pour décorés :p) :
Code:

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 <class name="Flux" table="FLUX"> <id name="id" column="F_ID" type="string" length="32"> <generator class="uuid"/> </id> <property name="name" column="F_NAME" type="string" length="40" unique="true"/> <property name="dateInsertion" column="F_DATE_INSERT" type="timestamp" update="false"/> <set name="messages" inverse="true"> <key column="MESSAGE_FLUX"/> <one-to-many class="Message"/> </set> </class> <class name="Message" table="MESSAGE"> <id name="id" column="M_ID" type="string" length="32"> <generator class="uuid"/> </id> <property name="etat" column="M_ETAT" type="long" length="1"/> <property name="offset" column="M_OFFSET" type="long"/> <many-to-one name="fluxEntree" class="Flux" column="MESSAGE_FLUX"/> </class>
Voilà, a partir de cet exemple "bateau" comment définir un paramétrage de chargement correct ? J'aimerais tenir compte de problème de performance et admettons que l'on peut avoir dans un flux, de 1 à 10.000 messages.

Mon "idée" de solution :
A priori dans hibernate 3.1 lazy est par défaut à false, donc pas besoin de le mettre. Maintenant je placerait peut être un batch_size sur la liste des messages dans la définition du flux ? Faut il poser un fetch="join" sur le "many-to-one" également ?

Merci d'avance pour toute l'aide que vous pourrez m'apporter :)
Et n'hésitez pas à partager vos propres exemples, mon but est d'essayer de comprendre le mécanisme des chargements qui me paraît important pour les grosses bases de données.

EDIT : j'ai oublié de préciser que je voulais bien sur eviter les fameux N+1 select

06/07/2007, 16h22
grishka

fetch join : résoud le prbl du N+1 select, mais la taille du resultats transitant entre la base et l'application sera proportionnel au nombre de message.

batch : effectue M select avec M = N/S +1, S étant la taille du batch, N le nombre de message.

donc perso je choisirai :

fetch join : si je suis sur d'avoir besoin de toutes les données pour faire un traitement. Même si le total des données transitant est plus faible dans le cas des batch (car aucune jointure n'est faite), dans la plupart des cas le fetch join sera plus performant

batch : si je ne suis pas sur :P

d'autres solutions plus fonctionnelles existent. Si ton besoin est d'afficher une liste de messages à l'utilisateur : utilise plutot un système de pagination avec fenêtre glissante :)

Par contre le choix d'une méthode fixé dans le mapping est à mon avis une mauvaise idée. Je te conseille de faire ca via l'API
06/07/2007, 16h34
ReiVon

Merci pour cette première réponse :). J'avou que c'est difficille de voir ce qui doit être utilisé et a quel moment.
10/07/2007, 10h21
ReiVon

Grégory j'ai exploré tes solutions et réalisé quelques tests (sans grande prétention, il faudrait pousser beaucoup plus loin).

Je suis tombé totalement d'accord avec toi sur le principe suivant :

Citation:

Le choix d'une méthode fixé dans le mapping est à mon avis une mauvaise idée. Je te conseille de faire ca via l'API

J'ai remarqué qu'il fallait rester très général dans le mapping et être beaucoup plus précis lorsque l'on réalisait les requêtes, notamment en mettant des fetchs join et en réalisant un découpage très précis des requêtes.

J'ai également tester avec la clé suivante : hibernate.jdbc.batch_size avec une valeur de 10. Je trouve cela très utile pour un mapping qui manipule beaucoup de collection. J'ai pu constater des améliorations.

Tout cela nécessite apparemment un gros travail de réflexion sur le mapping et les requêtes nécessaires à l'application. On peu vite arriver à des temps d'exécution catastrophique.

Comme je l'ai dit plus haut je penses que j'ai besoin de réalisé beaucoup plus de test pour me faire une idée de chaque "composante" existante. N'hésitez pas à partager votre expérience, ça m'interresse ^^.