Discussion :

[stof]

Bonjour,

J'ai en base un identifiant d'une table de type NUMBER.
Côté DAO, je fais une requête qui me récupère une liste de ces identifiants sous certains critères via

Code :

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

1
2
3
 
List<Integer> res = new ArrayList<Integer>();
res = (List<Integer>) aQuery.getResultList();

Et bien quelle surprise de voir que malgré ce que je demande, ça refuse de me faire une List<Integer> mais quand je regarde le détail, c'est des éléments de tyope BigDecimal que j'ai (autrement dit ça se fiche de la conversion que je demande). C'est ennuyeux quand j'utilise cette liste dans la suite du code et que j'en attends des Integer...

Alors certes je peux parcourir ma liste d'élements et les convertir un par un, mais c'est stupide et coûteux...

Qu'en pensez-vous?

[stof]

Ca n'inspire personne cette histoire...

[DevServlet]

Code :

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

J'ai en base un identifiant d'une table de type NUMBER.

Normal j'ai deja eu ce souci, les Number sont mappés en BigDecimal, faudrait que tu recuperes en List<BigDecimal> aussi, mais dis moi est ce vraiment vérifié l'utilisation de "NUMBER" coté base? un simple int ne te ferait pas l'affaire?

[stof]

est ce vraiment vérifié l'utilisation de "NUMBER" coté base? un simple int ne te ferait pas l'affaire?

Là, c'est pas moi qui ai conçu la base de données, et je doute qu'ils révolutionne tout ce qui est en prod pour la partie que je développe. M'enfin sortir un type qui veut pas être casté, c'est fort quand-même!

[DevServlet]

On se comprend peut être pas, si tu peux pas modifier niveau base, pourquoi tu ferais pas ca :

Code :

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

1
2
List<BigDecimal> res = new ArrayList<BigDecimal>();
res = (List<BigDecimal>) aQuery.getResultList();

[tchize_]

Et bien quelle surprise de voir que malgré ce que je demande, ça refuse de me faire une List<Integer>

En même temps, avec un peu de base en java, on sais que le casting, ca sert à expliciter au compilateur qu'on sais quel format on aura en sortie, pas à forcer la méthode appelée à subitement changer de comportement. Tu veux des Integer, ben mappe ces colonnes hibernate correctement sur des integer dans tes fichiers de config, et pas sur des big_decimal!
C'est à l'appelant de ce conformer à la signature d'une méthode, pas à la méthode de deviner (et comment elle le pourrait) à quoi ressemble le code de l'appelant!

[stof]

pourquoi tu ferais pas ca :

Code :

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

1
2
List<BigDecimal> res = new ArrayList<BigDecimal>();
res = (List<BigDecimal>) aQuery.getResultList();

Parce que le but c'est de récupérer une list d'Integer en sortie.

Tu veux des Integer, ben mappe ces colonnes hibernate correctement sur des integer dans tes fichiers de config, et pas sur des big_decimal!

Je me rend compte que j'ai mal expliqué ce que je faisais : en fait sur ce coup-là, c'est une requête en createNativeQuery, c'est pour ça (effectivement si je demandais un champ Integer d'une classe Hibernate, ça ne poserait pas de problème).
Mais ce qui m'étonne donc, c'est qu'un NUMBER ne puisse pas être casté en Integer (puisque de toutes façons aQuery.getResultList doit être casté, j'imaginais naïvement pouvoir caster en Integer tant qu'à faire...)

[stof]

Bon, je suis retourné à une requête utilisant les classes Hibernate.

[tchize_]

Mais ce qui m'étonne donc, c'est qu'un NUMBER ne puisse pas être casté en Integer

En même temps, un Integer est un Number, mais un Number n'est pas nécessairement un Integer! (ça peut être un BigDecimal comme tu l'a découvert). Avec une requete native, le type a la sortie est décidé par le driver jdbc en fonction de la colonne.