Hibernate version:

3.0

Name and version of the database you are using:

Postgresql 7.4.7

Hello

Je n'arrive pas à m'expliquer le comportement suivant sous H3 (via Spring), dans mon exemple je cherche à charger l'élément InfoFlash le plus récent d'une table en utilisant la fonction SQL max(id) (l'id est suffisant comme dénominateur), et je souhaite cacher ce résultat.

Le code :

final String query = "from InfoFlash as i where i.id = (select max(id) from InfoFlash)";

HibernateCallback callback = new HibernateCallback () {
public Object doInHibernate(Session sess) throws HibernateException, SQLException {
Query q = sess.createQuery(query).setCacheable(true);
Object o = q.uniqueResult();
return (InfoFlash) o;
}
};
return (InfoFlash) getHibernateTemplate().execute(callback);

Lors du 1er appel, les logs SQL montrent que la requête utilisant le max() est la seule effectuée en base.

Mais dès les appels suivants, la requête max() n'est plus effectuée, mais remplacée par une requête select utilisant en clause where le id ramené lors du max() précédent.

Je n'arrive pas à m'expliquer pourquoi le 1er appel sait à la fois trouver le max et ramener la row, alors que le 2e connaissant déjà le max a quand même besoin de faire un select, n'étant apparemment pas caché.

Qqun peut-il m'éclairer ?
Merci

laurent

C'est ta requête qui est mise en cache seulement pas les instances de la classe InfoFlash

Si tu ne veux pas de requête les fois d'après met une ligne <cache usage="read-write"/> dans ton fichier hbm.xml de InfoFlash

Quand à savoir pourquoi tu n'as pas la requête par id la première fois, je pense que c'est hibernate qui fait une jointure dans ta requête max(id) pour pouvoir charger les éléments directement à partir de cette requête pour éviter le n+1 select

En effet, le cache usage="read-write" annule en effet les requêtes suivantes.

Pour info la première requête générée est apparemment sans JOIN, pourtant H3 arrive bien à trouver le max et charger la dernière InfoFlash à partir de cet id :

select infoflash0_.id as id, infoflash0_.title as title49_, infoflash0_.extended_title as extended3_49_, infoflash0_.body as body49_, infoflash0_.picture as picture49_, infoflash0_.date_publication as date6_49_, infoflash0_.is_archived as is7_49_ from info_flash infoflash0_ where (infoflash0_.id=(select max(infoflash1_.id) from info_flash infoflash1_))

Enfin, ça marche bien donc bon..
Merci :)

Ce que tu peux voir c'est que cette requête charge bien l'ensemble des éléments d'infoflash (title, ....).

A partir de cela, le setCacheable, récupères la colonne id et associe en mémoire ta requête avec la liste des ids récupérés.

Si tu refais ta requête plus tard, il va récupérer la liste des ids et ensuite il y a deux possibilités : soit les objets sont en cache et il les récupère soit ils ne le sont pas et il va faire un select en base pour chaque id.

Il faut remarquer que mettre une requête cacheable sans mettre les objets retournés par cette requête en cache peut amener à dégrader les perfs car on obtien n requêtes au lieu d'1

seb