Qtd de registros em um resultset

bem-vindo ao Portal Java… não use o resultSet para outras coisas além de simplesmente puxar o dado do banco… popule uma Collection com o seu resultado e ai descubra esse tamanho pela collection :joia:

ou você faz via sql , SELECT COUNT(NOME_DO_CAMPO)
ou o método size() de uma Lista

matheus,

agora porque usar a collectione nao o resultset?
no caso eu teria que fazer dois laços, um para popular a collection com o resultset e outro para manipular a collection do jeito q eu quizer!
nao?

e se a consulta retornar varias colunas? como eu colocaria isso na collection?

vlw,

Um ResultSet é um objeto totalmente referente a persistência, seu trabalho começa e termina na persistência. Um ResultSet existe para buscar dados do banco, ele foi feito para isso, ele possui métodos para recuperar os dados das colunas de um resultado. Não tem por finalidade ser ordenado nem classificado, e muito menos ter métodos utilitários para isso.

Exatamente.

Think OO. Qual o problema de se retornar várias colunas? Vc esta trabalhando com objetos, essas colunas nada mais são do q atributos de uma classe, por ex:

while ( rs.next() ) {

   myArrayList.add(

      new Person( 
         rs.getLong( "id" ), 
         rs.getString( "name" ),
         rs.getString( "lastname" )
      )
   );

}

Eu uso getRow do resultset, sem problemas.

certo… certo… certo…
neste caso que voce falou tudo bem:

Acrescentando.
Primeiro mova resultSet para o último registro (usando last) e depois use getRow, isto pq este último retorna o número do registro corrente. Não existe um getRows.

[quote=“indivito”]certo… certo… certo…
neste caso que voce falou tudo bem:

hmmm
voce pode falar alguma coisa a mais sobre esse tal de “lazy loading” nunca vi isso…
e esse objeto gordao seria um objeto com uma collection para cada coluna? ainda assim seria melhor trabalhar com esse objeto gordao com que com o resultSet???

lazi loading é o ato de vc só puxar do banco oq precisa, por ex, vc tem a tabela Contract, e a tabela Invoices, onde 1 contract tem “n” invoices… e tu quer mostrar somente os contracts para o usuario, se vc faz uma pesquisa por todos os Contracts do banco, vai vir junto seus invoices carregados nesses objetos contract… lazi loading é vc ter um DAO pra Contract e outro pra Invoices, e um objeto de negócio q decide se vc vai carregar esses invoices juntos ou não…

e esse objeto gordão seria uma Classe q teria como atributo todas as colunas vindas no resultset, entendeu? ai vc terá uma collection desse objeto… e não uma collection pra cada coluna… :roll:

hmm
sakei.
mas tipo…
esses objetos gordos.
se eu tiver um consulta com um inner joinzão soh em UM lugar na aplicação.
seria mais interessante criar esse “objeto gordo” como uma classe interna da classe aonde ta a consulta ou uma externa mesmo?
eu descobrir que se pode criar classes dentro de classes um dia desses…
quando se deve usar isso e porque?

vc deve criar classes internas qnd sabe q aquela funcionalidade só é realmente relevante para aquele trecho de código, como por ex, em programação GUI, vc tem classes internas pra tratar eventos…