Salut tout le monde,
 
Est-il possible, en utilisant EJB-QL 2.0, de construire une clause WHERE IN (...) de manière dynamique ?
 
Je souhaiterais filter les données sur base multi-critères. La clause pourrait être WHERE IN ('a', 'b') mais aussi ('a', 'b', 'c'), avec un nombre variable de paramètres dans la clause IN.
 
J'ai naïvement successivement essayé :
 
- De construire la clause WHERE IN (?1) en passant String s = "'a', 'b', 'c'" -> aucune ligne retournée;
- Dans une tentative de hacking, je me suis dit que le paramètre ?1 était remplacé par '[la chaîne s]', et que donc, je devrais essayer de ne pas passer les guillemets simples ouvrants et fermants : String s = "a', 'b', 'c"; -> idem;
- De passer une collection pour le troisième paramètre -> ça ne compile même pas.
 
Existe-t-il une solution élégante et efficace, sans devoir passer par JDBC ?
 
Merci.  

 
A ma connaissance tu ne peux pas. Par contre, tu peux overrider ta query EJB-QL par un truc proprio.
 
JBoss par exemple te permet de passer certaines limitations d'EJB-QL. Quand au fait que la clause IN est dynamique, j'ai un doute ...
 
C'est quoi ton application server?
 

BEA Weblogic 6.1 :-/
 
"overrider ta query EJB-QL par un truc proprio" -> tu penses à quoi ? C'est application-server specific ?
 
J'ai bien sûr cherché avant de poser la question ici, mais j'ai rien trouvé. J'ai aussi un sérieux doute, mais bon, comme c'est finalement un cas tout à fait commun (filtrer sur plusieurs critères possibles), je trouve que c'est un peu laid de devoir passer par un "override".
 
La tentation d'exécuter le query EJB "complet" sans la clause WHERE IN, puis de filtrer la collection retournée est grande. C'est élégant, mais ça cache une complexité ayant un impact très négatif sur les perfs.

Oui, c'est application-server specific.
 
Weblogic 6.1, laisse tomber

Parce que tu crois que j'ai le choix  

nan, le 'in' c'est intrinsèquemen statique.
 
on peut avoir un peu plus de contexte ?
 
et non ?1 n'est pas remplacé par la chaine de caractères, sûrement pas, jamais, plutôt mourrir. C'est un vrai binding abstrait.
 
edit : bingo  
 
cmp_path_expression [NOT] IN ({literal|input_parameter}[, {literal|input_parameter]*)
 
ça veut dire que le cardinal est fixé à la compilation (du SQL , donc).

Exemple de contexte (je simplifie car le cas d'espèce est trop abstrait en changeant les noms de table et de champs) : j'ai une table "transactions" dont un des champs est "status". Status peut prendre plusieurs valeurs : "alpha", "beta", "gamma", "delta".
 
Je veux pouvoir retrouver une collection d'entity beans qui corresponde à la liste des "transactions" ayant un "status" donné, ou une combinaison d'un certain nombre de "status" :
- tous les "alpha";
- tous les "beta" et tous les "gamma";
- tous les "delta" et tous les "alpha" et tous les "gamma";
- etc
 
Si je travaillais en JDBC, je construirais p.e. dynamiquement la clause IN du query, qui ressemblerait respectivement à :
- IN ('alpha');
- IN ('beta', 'gamma');
- IN ('delta', 'alpha', 'gamma');
 
en fonction d'une collection de "status" passée en paramètre (une clause WHERE avec des OR donnerait un résultat identique).
 
C'est ce que j'entends par "dynamique". Un cas somme tout élémentaire, mais qui ne semble pas se prêter à un query EJB dirait-on, et c'est fort regretable.

les valeurs prises par le champ "status", elle sont en nombre fixe ou c'est appellé à augmenter ?
 
là je songe à un index sur "status", puis autant de Select que nécessaire dessus.

C'est en nombre à peu près fixe. Dans le cas présent, il y d'autres alternatives, mais je reste sur ma faim. Si d'aventure le nombre de "filtres" venait à s'élargir, on aimerait avoir en tête une solution robuste et généralisable sous la main.
 
Plusieurs selects : bof bof bof. Sur le temps de réponse total, la communication application server / database n'est pas négligeable. Répeter les selects, c'est pas top. Outre le fait qu'il faille ensuite concatener les différentes collections retournées.

ah non !!!!!
 
page 249 :
{single_valued_cmr_path_expression | identification_variable | intput_parameter} [NOT] MEMBER [OF] collection_valuated_path_expression

1) on est *dans* le serveur là
2) rien de t'oblige à les tirer tout de suite de la bdd
3) la concaténation est gratuite chez les gens normaux.

(les fautes dans les non-terminaux de la grammaire, c'est parce que je les tape à la main, ils parlent à peu près bien anglais chez java)

EJB-QL BNF : tu pourrais être plus explicite sur le passage qui tu cites ? Je ne parviens pas à faire le rattachement avec where_clause ::= WHERE conditional_expression, si c'est de ça dont tu veux parler.
 
1) SELECT -> heu envoyé par l'application server au dbms, qui l'exécute et renvoie le résultat (?!?)
2) "Les tirer de la db" -> mais si tu fais l'appel à la DB, beh, il est fait, l'appel ?
3) Oui, c'est pas un problème.
 
J'ai un peu de mal à te suivre, ce soir, sans doute besoin d'un peu de repos, ne m'en veux pas.  

c'est ptet con, mais tu peux pas filer une collection ou un array comme argument a ton ejbql?

J'ai essayé le coup de la collection, dans la série "essaye pour voir ça va p'têt marcher", mais ça compilait pô - pas noté le message, j'ai laissé de côté dans un coup de rage et j'ai pris la solution dirty  

pour la BNF : ce que je cite est  
collection_member_expression ::= <mon truc d'au-dessus>
 
et collection_member_expression, c'est une simple_cond_expression.
 
en clair :  

et tu bindes un Arrays.asList(new String[]{"pipo", "pipi"}) sur l'argument 1.
 
ça fait *exactement* ce que tu veux.

keske je disais

sircam >> ton finder etait probablement pas bien déclaré !?
tu utilises xdoclet ou tu fais tout à la main?

 
Mais c'est tout con ! Voilà, j'étais passé à côté. Merci beaucoup. C'est super élégant. Je vais bien dormir cette nuit.
 
Bien vu !
 
Real : je fais tout à la main  

quand je pense que j'ai jamais développé une appli J2EE de ma vie et que je demande que ça ...

Beuah   ?
 
Bof, on en revient.

J'en suis *déjà* revenu, mais c'est le seul moyen de rentrer en dev. Et puis il doit y avoir des aspects que j'avais pas vu, comme quand je me suis lancé dans les javabeans.

Ca marche pas avec Weblogic 6.1 ! Repli sur la solution "dirty".

keski marche pas avec wl ?

Beh, le MEMBER OF. EJBC rouspète, syntaxe incorrecte. Et effectivement, on en trouve trace dans la doc 7.0, mais rien en 6.1...

c'est l'occasion de convaincre les décideur de jeter cette merde

C'est pas comme ça que ça marche, faut pas rêver :-/
 
A l'echelle du projet, ce genre de soucis est sans importance aucune et ne remet pas en cause le choix de l'architecture...

je te parle plus des outils que de l'architecture

Ca reste d'autant plus d'application.
 

 
bin vi, je t'avais dit de laisser tomber

tu avais surtout dit qu'il n'y avait pas de solution standard

Bah, j'avais une solution, mais je c'était pour la beauté du geste, pour faire propre.
 
Au moins, on a appris qq chose.

 
Et que weblogic 6.x est une belle merde au niveua implémentation (que ce soit le standard ou pas d'ailleurs).

J'ose espérer que ça s'améliore avec la version 8 et la 9 à venir...

elle vient pas de sortir la 9 ?

en beta, non ?

han lalalala, il insulte le nouveau modo !!!

Pas de pollution de mon topic  

http://today.java.net/pub/n/2037