On 21/02/2012 17:22, Eric Chatellier wrote:

Bonjour,

J'ai un problème avec les topia query, je trouve ça complètement illisible et inmaintenable sans le commentaire qui va avec (et encore...)

Un petit exemple: http://nopaste.info/42be32d097.html

C'est sans doute dû à la combinaison des alias et des properties : .addInElements("E." + ClosedPeriodicEntryBook.PROPERTY_FINANCIAL_PERIOD, "F." + FiscalPeriod.PROPERTY_FINANCIAL_PERIOD) au lieu de simplement "E.financialPeriod IN F.financialPeriod"

Certes, c'est "compilé", mais c'est très difficilement lisibles.

Avez vous des retours la dessus sur des exemples compliqués et des sous requêtes ?

Je suis d'accord, mais cela n'est pas dû à la TopiaQuery mais au HQL en général. D'où mes idées de générer les propriétés un peu plus façon DSL avec le TopiaQueryHelperTransformer (je ne suis plus sûr du nom). Mais je pencherais plus pour d'autres solutions comme queryDSL ou sinon tout simplement du "full text" pour les requêtes et donc plus de noms de propriétés en constantes statiques. J'ai l'impression de revenir en arrière en disant ça, mais la problématique reste pas évidente et les solutions diverses. Je n'ai pas encore trouvé LA solution pour avoir des requêtes à la fois lisibles et sûrs (en mode objet et donc compilable). Ça reste toujours mieux que l'api Criteria de la JSR. Mais ce n'est que mon point de vue évidemment. L'idée de la TopiaQuery c'est ce petit mélange HQL/Objet. Cela garde la souplesses du HQL pour les requêtes compliquées et évite de rajouter X méthodes spécifiques. En contre-partie tu as une plus grande facilité de créer des requêtes dynamiques avec conditions, ce qui devient très vite illisible en concaténant un String HQL. La question donc : As t'on un réel intérêt à utiliser de façon systématique les constantes pour les noms de propriété ? On sait tous que finalement, on ne change pas tous les 4 matins les noms des champs ! De plus si toutes les requêtes sont dans les DAO, le refactor reste ciblé. J'ouvre un troll, mais cela mérite le débat.