Discussion :

[death_style]

Bonjour,

J ai la fonction getResultList() qui retourne un tableau d'un résultat sql, genre:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
 
Query query = entityManager.createNativeQuery("select a from table");
malist = query.getResultList();

ça me retourne la listes des éléments 'a'.

Moi je veux avoir le résultats d'une requête récupère plusieurs colonne et non seulement une.

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

select a, b,c from maTable

comment faire ?
merci pour l'aide

[OButterlin]

comme tu as noté

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
 
select colonne1, colonne2, colonne3 from table

Au retour, tu as une liste de tableau d'Object à traiter où tbl[0] correspondra à colonne1, tbl[1] à colonne2 etc...

[DevServlet]

On peut savoir pourquoi tu fais une nativeQuery? plutot qu'une requete HQL?

[death_style]

Au retour, tu as une liste de tableau d'Object à traiter où tbl[0] correspondra à colonne1, tbl[1] à colonne2 etc...

je vais voir ça merci

On peut savoir pourquoi tu fais une nativeQuery? plutot qu'une requete HQL?

Je veux en profiter de certaines fonctions sql sur les attributs. plutôt que de créer les objets les parcourir et faire le traitement en java.

[OButterlin]

On peut savoir pourquoi tu fais une nativeQuery? plutot qu'une requete HQL?

Dans beaucoup de cas, lorsqu'il s'agit de recherche d'informations (filtrage, etc) les requêtes natives sont plus performantes (choix de chemin d'accès).
Pour ce qui est du modèle "métier", ma préférence va bien sûr aux entity

[death_style]

comme tu as noté

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
 
select colonne1, colonne2, colonne3 from table

Au retour, tu as une liste de tableau d'Object à traiter où tbl[0] correspondra à colonne1, tbl[1] à colonne2 etc...

Je peu pas faire ça , le getResultList retourne une List et non un tableau. donc je ne peux pas faire un truc tb1[0] ....

[geforce]

pour quoi pas plus tôt ça:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
       public List<Type> findAll() {
        try {
            CriteriaQuery cq = getEntityManager().getCriteriaBuilder().createQuery();
            cq.select(cq.from(entityClass));
            return getEntityManager().createQuery(cq).getResultList();
        } catch (Exception ex) {
            getLogger().log(Level.INFO, "Exception lors de l''appel au service " + entityClass + "Impl.findAll {0}", ex.getStackTrace());
            return null;
        }
    }

le reste ces du java et la gestion des liste dans des boucle

[OButterlin]

Je peu pas faire ça , le getResultList retourne une List et non un tableau. donc je ne peux pas faire un truc tb1[0] ....

je fais ça à longueur de temps, je peux t'assurer que ça fonctionne.
le getResultList() te renvoie une List<Object[]>

[OButterlin]

pour quoi pas plus tôt ça:

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
    public Type find(Object id) {
        try {
            return getEntityManager().find(entityClass, id);
        } catch (Exception ex) {
            getLogger().log(Level.INFO, "Exception lors de l''appel au service " + entityClass + "Impl.find {0}", ex.getStackTrace());
            return null;
        }
    }

le reste ces du java et la gestion des liste dans des boucle

Un find te renvoie une instance d'une entité, pas une liste (correspondant par exemple à des critères de sélection)

[fr1man]

Dans beaucoup de cas, lorsqu'il s'agit de recherche d'informations (filtrage, etc) les requêtes natives sont plus performantes (choix de chemin d'accès).
Pour ce qui est du modèle "métier", ma préférence va bien sûr aux entity

C'est éventuellement plus rapide si on se sert de fonctionnalités particulières à la base de données, comme le choix d'index particulier.
Si c'est juste pour faire un select a from b, ça n'a pas trop d'intérêt à mon sens.

[OButterlin]

Si c'est juste pour faire un select a from b, ça n'a pas trop d'intérêt à mon sens.

Même pour un simple select ça peut avoir du sens si la table à beaucoup de colonnes et/ou une taille d'enregistrement élevée.

[fr1man]

Effectivement, mais dans ce cas, on est dans un cas particulier.

[OButterlin]

pas tant que ça...
Dans le cadre de recherches, pourquoi s'embarrasser à extraire des colonnes dont on n'a pas besoin dans les vues (au sens IHM)...
Sans compter que des jointures judicieuses peuvent booster les requêtes.

[fr1man]

Tout ça est faisable sans passer par du SQL pur.

[death_style]

Merci pour vos réponse,
ça marche nikel bien avec ça :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
 
List<Object[]> list = query.getResultList(sql);
 
for (Object[] object : list) {
 
      for (int i = 0; i < object.length; i++) {
                System.out.println( object[i].toString());
      }
}

merci OButterlin

Sinon, mon avis sur le sujet , personnellement , je trouve que dans certain cas, (parfois nombreux faut l'avouer ) l sql ordinaire et de loin meilleur qu'un traitement sur les objets en java. (traitement sur les Dates, les jointure les GROUP BY et surtout les COUNT.