De toute
façon si tu utilises des criterias ou des requêtes hql, le résultat devrait être le même en SQL. C'est une certitude de ta part ou juste une supposition ?
Le mieux c'est de regarde les requètes passées.
Et bien au vu des tests de perf, les criteria sont plus long a l'execution sur un Thread qui tourne en boucle qu'avec de simple HQL, index de base ou non.
dans tous les cas, je suis vraiment pour qu'on retravaille un peu les DAO de ToPIA car dans tous les cas le code n'est pas optimisé du tout... : remonter toute une partie de la base pour juste ensuite en java faire des boucles pour récupérer les résultats qui nous intéresse c'est pas top. Cela fonctionne tant qu'on a pas de gros volumes de données à traiter, non ?
En fait ca va les criteria était assez optimisé au niveau requetage pour les DAO, alors pour la durée d'execution je suis toujours dubitatif... Le problème vient vraiment de la limitation des méthodes proposés, de simple findBy ne suffisent pas toujours... D'ou l'interet d'utiliser un systeme de requetage comme TopiaQuery, simple et complet
Alors l'idée, est-ce que ça vous convient de remplacer les criteria par l'utilisation de TopiaQuery ? Tu vas pas réussir à avoir les mêmes possibilités que les criterias ou la syntaxe hql. Juste un exemple comment tu fais pour faire des jointures ou des sous-requêtes ?
En fait le principe du TopiaQuery, c'est que tu manipule une requete HQL donc, t'en fait ce que tu ve, tu peu la construire comme tu ve donc aucun probleme pour les jointures ou les sous-requetes, ce sont simplement des bouts de HQL.
Ca me rappelle un peu Sandra avec des requêtes qu'on peut qualifier de monstrueuse,non Julien :) Dans tous les cas cela ne change rien à la problématique des DAO de ToPIA. Tu pourras toujours faire des requêtes de folies en récupérant la session hibernate, donc je vois le fondement de ton objection :)
Heu certes récupérer la session hibernate permettrait d'utiliser les Criteria, mais alors l'application cliente devient fortement dépendante d'Hibernate...
Il s'agi juste de remplacer l'utilisation des Criteria dans les findXXX dans les DAO générés qui n'utilisent pas (je pense, mais j'en suis pas sûr...) de sous-requêtes ou jointure; j'espère ne pas me tromper ;)
La dessus aucun souci, le gain de vitesse d'exécution est flagrant dès qu'on utilise directement du HQL plutot que des Criteria ! Reste a savoir pourquoi ! Sur ce, je pense commité sur Topia ces quelques modifs : - Passage du TopiaQuery en generic (la requete doit toujours au minimum tapé sur une table/entité pour être exécuté) avec methodes static pour instanciation. - Remplacement de l'utilisation des Criteria dans TopiaDAOImpl par l'utilisation du TopiaQuery. - Ajout de methodes dans le TopiaDAO (interface) pour crée simplement des instances de TopiaQuery correspondant a l'entité du DAO, pour etre ainsi manipulé aisément dans l'application cliente : ex : SampleRowDAO dao = SuiviObsmerModelDAOHelper.getSampleRowDAO(transaction); TopiaQuery<SampleRow> query = dao.createQuery().add(SampleRow.CODE, Op.LIKE, year + "_%"); ... Pour clore le débat, sur un import d'un CSV de 86000 lignes, je suis passé de plus de 10h d'execution en utilisant les anciens findBy (Criteria), à 2min en utilisant du HQL.