Tipo de dados do resultado SUM no MySQL

Question

Eu estou tendo um pouco de um problema com a conversão do resultado de uma consulta MySQL para uma classe Java ao usar SUM.

Ao executar uma simples soma no MySQL

SELECT SUM(price) FROM cakes WHERE ingredient = 'chocolate';

com price sendo um inteiro, parece que o SUM às vezes retorna uma string e às vezes um inteiro, dependendo da versão do driver JDBC.

Aparentemente, o servidor faz dizer ao driver JDBC que o resultado da SUM é uma string, e o driver JDBC, por vezes, 'convenientemente' converte este para um inteiro. (Veja Marc Matthews' explicação ).

O código Java usa algumas BeanInfo e Introspecção para automagicamente preencher um (lista de) feijão (s) com o resultado de uma consulta. Mas isso, obviamente, não pode funcionar se os tipos de dados diferem entre servidores onde o aplicativo é implantado.

Eu não me importo wether eu recebo uma string ou um inteiro, mas eu gostaria de ter sempre o mesmo tipo de dados, ou pelo menos saber com antecedência que tipo de dados que estará recebendo.

Existe alguma maneira de saber qual tipo de dados será devolvido por um SUM MySQL de dentro do código Java? Ou alguém sabe alguma maneira melhor de lidar com isso?

Answer 1

Este é apenas um palpite, mas talvez lançando para inteiro irá forçar o MySQL a sempre dizer que é um inteiro.

SELECT CAST(SUM(price) AS SIGNED) FROM cakes WHERE ingredient = 'marshmallows';

Answer 2

Eu nunca trabalhei com MySQL antes, então eu não posso dizer isso, mas se você diz:

ResultSet rs = statement.executeQuery("SELECT SUM(price) FROM cakes WHERE ingredient = 'chocolate'");
int sum = 0;
if(rs.next())
size = Integer.parseInt(rs.getString(1));

Em seguida, você não deve ter um problema, independentemente do tipo de dados retornado como a documentação diz:

Cadeia getString (int columnIndex) lança SQLException

recupera o valor da coluna designada na linha de corrente de este objecto ResultSet como uma cadeia na linguagem de programação Java

Answer 3

Eu encontrei COALESCE(SUM(price),0) bom para sempre garantindo o campo retornado 0 se não houve resultado.

Veja: http://lists.mysql.com/mysql/177427