Version imprimable
Bonjour,
Je construis une frame de recherche d'objets à partir d'attributs.
Genre: tous les établissements ayant le codePostal=59000
ou: tous les établissements ayant le nom comme %tot% et dont la ville est Lille.
Je me tourne vers les setParameters, les '?'. Mais comment faire pour que mes critere de recherche soit dynamique. (Apres le where) .Je peux en avoir qu'un comme plusieurs.
Merci de votre aide.
je me suis posé la même question et je n'utilise plus "dans certain cas" les setParameter
c'est ce que tu voulais ?Code:
2
3
4
5
6
7public List Marequete(String MaTAble, String MonChamp, String MaValeur){ String requete = "select id from `"+MaTAble+"` where `"+MonChamp+"`="+MaValeur; Query oQuery = entityManager.createQuery(requete); return oQuery.getResultList(); }
Oui c'est à peu pres ca. Sauf que j'utilises un business pattern. J'aimerai donc que dans ma couche graphique il n 'y a aucune notion de sql ou autres.
En plus, le nombre de criteres apres le where n 'est pas forcément fixe.
J'ai regardé du cote de hibernate criteria. Apparrement cela répond entièrement à ce que je veux.
Mais par contre faut appeler session dans la ligne suivante:
Mais le problème est que je n'arrive pas à déterminer session. Je fais appel donc à un locator et un business delegate.Code:Criteria criteria = session.createCriteria(Preleveur.class);
Tu peux très bien le faire via l'entityManager, comme avec les EJB3.
Voici un exemple
Voilà, j'espère que ça t'aidera ;)Code:
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
Je te laisse rajouter les méthodes complémentaires...
A+
Je vais regarder ca et je vous tiens au courant.
Pourquoi tu ne construirait pas tout simplement ta requête de manière dynamique.
[Code à la volée... en admettant que tu es l'attribut conn de type Connection]
Code:
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
Merci c'est niquel je personnalise ca avec mon boulot.
Merci beaucoup à tous les deux.
la session Hibernate est le delegate de l'entity manager…Citation:
Envoyé par skyangel
-> dans votre DAO/Repository…Code:
2
3
4protected Session getHibernateSession() { return (Session)getEntityManager().getDelegate() ; }
(utilisez les Criteria : c'est la meilleure voie à suivre, car générer le SQL revient à imposer à la couche business de connaître le RDBMS sous-jacent…, c'est mieux de laisser cette responsabilité à l'ORM… )
100% d'accord dans le cadre d'une utilisation hibernate ! Sinon c'est clair que ça sert à rien de mettre en place hibernate...Citation:
(utilisez les Criteria : c'est la meilleure voie à suivre, car générer le SQL revient à imposer à la couche business de connaître le RDBMS sous-jacent…, c'est mieux de laisser cette responsabilité à l'ORM… )
Je donnais juste une solution simple (et me semle-t'il efficace) dans le cas d'une construction des requêtes à la main. (ce qui soit dit entre parenthèse colle avec le message initial ;))
Avec ma méthode, il n'y a aucune connaissance du RDBMS sous-jacent nécessaire.Citation:
Envoyé par JeitEmgie
Il faut bien sûr connaître le nom de la propriété dans l'entity, mais ça, personne n'y coupe :mrgreen:
Par contre quand le critere de selection se trouve dans un objet
En fait,
Personne possède une 'adresse'. Adresse possede un Objet 'Commune'
Le critere de selection se fait sur l'objet commune .
Est ce que en faisant
Je dois faire un left join sur les autres objets ? non ?Code:select c from Preleveur c where 1=1
comme par exemple:
Mais ca marche pas:Code:
2
3
4
5
6
7
8
Mes pojos:
Personne
possede Adresse
Adresse
possede Commune
Commune
cp
ville
Je recherche à filtrer par ville tous mes personnes. J'ai du mal avec les requetes JPQL etant donné que ce sotn des requetes sur objets
c'est pas le nom de la propriété qu'il faut connaître mais le nom de la colonne associée… ce qui est déjà une contrainte de maintenance…Citation:
Envoyé par OButterlin
(à moins d'utiliser Reflect pour accéder à l'annotation… et en extraire le nom de la colonne…)
quant à la connaissance du RDBMS, elle apparaîtra un jour où l'autre de manière sournoise au détour d'une optimisation de jointure, d'un cast de type, d'une fonction disponible dans tel SQL et pas dans un autre, …
mais évidemment tant que vous ne cherchez que dans des varchar de l'entité principale, vous êtes relativement à l'abri…
Citation:
Envoyé par OButterlin
up. Mais comment faire quand j ai des join à faire?
Je fais cete méthode là:
mais il n'aime pas les '.' du p.adresse.mCommune.villeCode:
2
3
4
5
6
7
Il me sort une erreur du type :
Par contre si je le mets directement dans la requete ca passe. En fait je pense que c'est dans la chaine String :p.adresse.mCommune.villeCode:
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
Vous avez une idée.
Il ne faut pas mettre le ":" dans la méthode addParameter...
(d'ailleurs dans l'exemple d'utilisation que je te donnais, il n'y en avait pas ;))
Pour ce qui est de la condition "where 1=1", c'est juste une "astuce" pour ne pas avoir à se poser la question du "where" ou "and" (la première condition nécessitant un where).
A+
Non non, c'est bien le nom de la propriété de l'entity qu'il faut connaître, pas du tout celui de la colonne dans la base (on est dans le cadre d'entity là)...Citation:
Envoyé par JeitEmgie
Et pour ce qui est de son type, sa ne fonctionne pas QUE avec des varchar mais bien avec tous les types (y compris class) grâce au format de la méthode setParameter(String, Object) (ou setParameter(int, Object))
Vive JPA ;)
oui de fait j'ai perdu de vue qu'ici vous générez du JPQL pas du SQL natif…Citation:
Envoyé par OButterlin
reste qu'utilisez les Criteria est plus efficace et beaucoup plus facile à faire évoluer…
Quand on développe uniquement avec Hibernate oui, mais là, on passe à n'importe quel JPA sans modification de code.
Personnellement, j'utilise cette technique (similaire en tout cas) avec EJB3, ça fonctionne parfaitement.
Dans un autre projet (non EJB) avec Hibernate, j'utilise Criteria également, je ne nie pas du tout le fait que ce soit puissant, juste restrictif...
A+