Conjunto de Resultados em JSP

Depois de ter o RecordSet com os resultados só tem que criar um ciclo para percorrer todos os registos, do género:

Imagine que a variavel do RecordSet é a rs.

while(rs.next) //Enquanto houver registos
{
   out.println(rs.getString("nome")); //vai buscar o campo nome
}

Isto vai fazer com que todos os nomes guardados numa tabela sejam imprimidos para o ecran.

PEACE!

Apenas complementando a resposta do morcego:

A idéia do Vector pode pareceber boa, mas no seu caso são muitos registros à serem adicionados, não é nem pelo limite de registros, mas pela quantidade de memória utilizada para armazenar todos estes dados.

A vantagem do ResultSet é que ele não retorna todos os dados encapsulados em um objeto, mas sim um “ponteiro” na base de dados, que vai “navegando” pelos dados à medida que o loop vai acontecendo

Bem, se você estiver trabalhando com camadas, essa solução não funciona legal(você não deveria acessar seus dados diretamente da JSP).

Você deve colocar tudo em uma Collection mesmo (mas não use Vector para isso). Se você acha que a Collection vai se tornar grande demais, você pode, ao invés, gerar um arquivo xml temporário. Á medida que você navega, você lê desse arquivo. Assim, você só tem em memória os dados referentes a página sendo exibida.

Espero que tenha sido claro…

Concordo com o Elvis

Mas acho que a solução do arquivo XML não seria necessária aqui… afinal, são relativamente poucos registros (2000 linhas).

Mas independente disto, a idéia de fazer a navegação diretamente pelo ResultSet independe de se acessar os dados diretamente da página JSP (o que não recomendo de forma nenhuma). Este serviço pode (melhor dizer “deve”) ser executado por beans.

Isso depende também do quão “dependente” da base de dados você se permite ficar

Bom, espero ter sido claro

Abraços!!

Estou trabalhando em 3 camadas e o vetor está estourando a cada apresentação. O meu maior problema é a paginação. Eu quero trazer do banco apenas o que vou apresentar, e não tudo como eu estava fazendo.

Bem. Em alguns bancos essa solução se torna difícil, em outros não.

Por exemplo, no PostgrSQL (esse banco é rochedo mesmo), você pode no seu select informar quantos registros você quer trazer do seu resultset. Você então só trabalharia com os parâmetros através do número da página. Já outros bancos não dão suporte a essa funcionalidade. O seu select sempre vai retornar todos os registros.

Acredito que a solução xml seja a melhor. 2000 pode ser pouco, mas imagine 10 pessoas acessando o site ao mesmo tempo, 20000 objetos na memória…

Assim que receber o resultset, passe os dados pro xml e guarde a referência na session do usuário. Quando a session expirar, delete o arquivo (ou mantenha ele e faça um cache de busca. muito útil)

Desculpe a ignorancia, mas o que seria uma Collection?

E já que mandei essa pergunta, qual a diferenca de Beans e Servlet?
Obrigado!

Se a paginação é um recurso necessário sem dúvida o XML é uma excelente opção!

Elvis, o recurso que você falou que só existe no PostgreSQL, se bem entendi, ele permite refinar uma busca, permitindo retornar uma quantidade definida (1000 de 5000 por exemplo) dos resultados de um select, é isso? Porque isso até onde sei, SQLServer, Oracle e até MySQL tem
Desculpe se entendi mal

Abraços!

Eh isso mesmo. Achava que o SQLServer só possuia o TOP.

Uma Collection é uma… bem… Coleção

Uma Collection armazena vários objetos e possúi vários métodos úteis para manipulá-los. Além do mais, ela fornece uma abstração para tratar com conjuntos de dados.

Beans são objetos em java que seguem uma série de regras. É um padrão utilizado no Java. Eles servem para encapsular dados. Geralmente ele possui uma série de propriedades e métodos get e set para manipulá-las.

Servlets são o equivalente do CGI em Java (só que com muito mais vantagens).

Complementando a resposta de Collections do Elvis:

Uma vez que Java não permite manipulação direta de memória, o uso dos arrays fica muito restrito (é preciso conhecer o tamanho maximo do vetor quando ele é declarado).

As coleções facilitam a utilização de estruturas de dados como Listas encadeadas, pilhas e filas

Abraços!

Pelo que entendí a respeito do assunto já discutido, a melhor saída seria utilizar XML para guardar os dados e fazer a leitura no XML para paginar quando necessário. A questão é:

Devo gravar um arquivo XML com o conteúdo do ResultSet e fazer a leitura posterior quando necessário navegar nos dados? Esta foi a recomendação para evitar que a quantidade de memória alocada não “estoure” pois se uma consulta tem 2000 registros, 20 usuarios com esta consulta terão 20000 registros. No entanto é sabido por todos nós que uma operação de I/O é infinitamente mais lenta que uma operação em memória. Isto me faz lembrar o custo de execução do modelo tradicional de CGI (recebe request, vai no disco, carrega pra memória, faz parse, executa o programa …). A diferença é que Servlets executam em multi-threading, mas não há grande vantagem nisso quando o I/O é o nosso maior problema. Sem contar que o custo de escrita para o disco me parece mais “pesada” do que somente a leitura do CGI. Não estou defendendo a utilização de CGI, fiz somente uma analogia para “questionar” se temos que conviver com problemas de I/O que ao parece muita gente prega que com Servlets, já é um problema do passado.

Se colocar o XML em um stream para evitar I/O e fazer a leitura do Stream já em memória quando necessário? Esta abordagem “parece” que resolve o problema de I/O, mas recai na discussão inicial, pode estourar a memória. Será que é melhor que uma collection?

Meus caros, será que não há uma solução padrão, um design pattern para este problema ? Afinal, é uma situação bastante comum paginar dados na internet. Veja o proprio exemplo no forum. Parece que foi feito em PHP, mas se fosse em Java, usaria uma solução padrão?

[]s, Welington B. Souza

Pra resolver esse problema criei uma classe Paginador :

atributos :

private int nuPaginas = 0;

private int nuRegistrosPorPagina = 10;

private int nuPaginasPorBloco = 5;

private int nuPaginaCorrente = 1;

private String query;

… // existem outros atributos

métodos :

public Paginador(String pQuery) {

query = pQuery;

// recuperar quantidade registros/páginas

// recuperar quantidade de colunas

}

public void irParaPagina(int pag)

public void proximaPagina()

public void paginaAnterior()

… // existem outros métodos

public Vector getPagina() { // retorna os registros da página corrente

// select recuperando apenas os registros da página corrente

}

Para saber a quantidade e os tipos das colunas do ResultSet, uso o ResultSetMetaData.

Faço também um controle se a quantidade de páginas for muito grande. Por exemplo:

Anterior  <<...  50  51  52  53  54  ...>> Próximo

Bom, essa solução faz um select no banco a cada mudança de página.
O que vocês acham dela? Aceito críticas e sugestões.
Não fiz teste com uma grande quantidade de registros, mas na minha aplicação funciona muito bem.