Passage de JPQL à Criteria API

Bonjour,

je voudrais transformé cette requête de JPQL (qui fait des jointures) vers Criteria API, mais j'ai prouve quelque difficultés vue que je n'ai pas l'habitude de trop manipulés du Criteria quand ces des jointure.

voilà la requête JPQL que je veux transformés :

Code:

---

1 2 3 4 5 6

public List<TRubriqueVar> ListerRubVarByCourentSociete(String codeSociete){ Query query = em.createQuery("select a from TRubriquepfixe a, TRubriqueVar e where a.codrub=e.rubVarPK.codrub and e.rubVarPK.codeSociete=:codeSociete"); query.setParameter("codeSociete", codeSociete); return query.getResultList(); }

---

Merci

Bonjour, voilà mon avancement mais j'arrive pas faire une dérniére étape (je crois que je n'est pas bien fait quelque chose !)
Sa faire une jointure mais sans récupérés les champs de l'autre table (TRubriquepfixe).

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18

public List<CentreComptable> findBySociete() {   CriteriaBuilder cb = getEntityManager().getCriteriaBuilder(); CriteriaQuery cq = cb.createQuery();   Root<CentreComptable> from = cq.from(TRubriqueVar.class); Join<TRubriqueVar, TRubriquepfixe> societes = from.join(CentreComptable_.societesfk);     CriteriaQuery<CentreComptable> select = cq.select(from); select.where(cb.equal(societes.get(Societes_.codeSociete), "ELIT"));   TypedQuery<CentreComptable> typedQuery = getEntityManager().createQuery(select); List<TRubriqueVar> resultList = typedQuery.getResultList();   return resultList; }

---

Merci de vos remarque.

Bonjour,

j'ai une question de débutant (vu que j'en suis un :p) :

pourquoi transformer tes query JPQL ? tu n'étais pas satisfait du fonctionnement ?
à quoi cela sert de passer sur du Criteria API ?

Tout simplement :

JPQL :
1- ce n'est ni du SQL ni de l'objet (pour quoi je vais apprendre ce type de chose barbare qui me servira pas plus que pour du JPQL alors qu'il y meilleur)
2- en ne peut détecter les erreurs que en Runtime (ça sait pas trais acceptable pour moi)

Criteria API :
1- Sa reste de l'objet (100% java ce que j'ai toujours fait)
2- En peux détecter les erreurs soit dans l'éditeur ou dans la Model s'il y a des changements (en utilisant le méta-model des entity)
3- Plus flexible et réutilisable (bref parfais pour construire une api perso de base


voilà,

Citation:

---

Envoyé par geforce

Tout simplement :

JPQL :
1- ce n'est ni du SQL ni de l'objet (pour quoi je vais apprendre ce type de chose barbare qui me servira pas plus que pour du JPQL alors qu'il y meilleur)
2- en ne peut détecter les erreurs que en Runtime (ça sait pas trais acceptable pour moi)

Criteria API :
1- Sa reste de l'objet (100% java ce que j'ai toujours fait)
2- En peux détecter les erreurs soit dans l'éditeur ou dans la Model s'il y a des changements (en utilisant le méta-model des entity)
3- Plus flexible et réutilisable (bref parfais pour construire une api perso de base


voilà,

---

Pas d'accord avec le point 1 sur JPQL, JPQL = Java Persistent Query Languauge, c'est justement un langage de requête orienté Java, donc Objet...
Le point 2 de JPQL fonctionne de la même façon via Criteria, si tu orthographies mal le nom d'un attribut d'un objet dans l'appel de ton criteria, ça ne plantera qu'à léxécution. Donc tes arguments ne justifient pas ton choix. Je peux comprendre que tu sois plus à l'aise sur une techno que sur l'autre tout simplement.
Pour moi les 2 techno ne sont pas du tout exclusives, elles peuvent même se compléter, JPQL prend sa force dans un parcours d'un modèle de persistence à la UML (notation pointée très interessante) alors que criteria c'est pour des requêtes complexes avec combinaison de plusieurs critères, des requêtes fortement dynamiques si tu veux, d'où son nom d'ailleurs...

Oui, mais moi j'ai dit Criteria plus Méta-Model (ce qui va faire ça force).

Dit ce n’est pas tout mais moi je bloc de puis un moment sur le sujet du poste que j'ai lancé (les 2 premier) si quelqu'un peux me filés un petite coup de pousse sa sera pas de refus.

merci