Tenha um aplicação WEB e estou travado em uma situação:
Tenho uma tela que anexo um arquivo PDF…
Depois de ser anexado eu pego esse arquivo e transformo em byte[] e gravo no MYSQL como BLOB.
Porém não estou conseguindo fazer o inverso, ou seja, preciso pegar esse byte[] que esta no banco e listar ele na tela, que seja em um link do tipo “Visualizar”… Como faço essa conversão? Para eu pegar no Front esse PDF?
Se vc puder salvar o arquivo em um diretório, por favor faça isso.
Não é pq vc pode enfiar bytes no banco de dados q vc deve fazer isso
I
igoorsp
Então… faltou essa informação… eu nao preciso armazenar esse PDF em nenhum lugar, pois ele só irá aparecer quando o “Cliente” logar e clicar em visualizar, então seria um arquivo TEMP…
A conversão para pdf só aconteceria na hora.
darlan_machado
Seria um arquivo temp que deveria ficar numa pasta temp e ser lido quando o usuário necessitasse.
Ou, o melhor dos cenários, esse arquivo deve ser gerado apenas quando o usuário clica em visualizar.
javaflex
Se o PDF é gerado em memória não precisa ir pra disco, basta responder esses bytes como já exemplificaram.
josiloch
Qual a justificativa de não poder salvar um arquivo no banco?
P
programador1225
A resposta se encontra neste post do stackoverflow : Link .
javaflex
Existem vantagens e desvantagens na forma de manter os arquivos salvos.
Por banco, integridade e transação do processo ficam garantidos, ao contrário de guardar os arquivos por conta própria. Então depende dos requisitos/exigências, que nem sempre o mais prioritário é o máximo de desempenho.
Via banco é importante armazenar os blobs em um tablespace próprio. Os SGDBs mais profissionais suportam.
I
igoorsp
O arquivo deve ser gerado apenas quando o usuário clica em visualizar. Logo depois pode ser descartado.
I
igoorsp
Eu salvo ele no banco… mas salvo com byte, porém a conversão dele para PDF que não vou salvar em lugar algum, apenas quando o usuario solicitar.
darlan_machado
Se essa é a regra, não tem necessidade de armazenar no banco de dados. Você está usando uma estrutura limitada (banco de dados) para armazenar algo volátil.
javaflex
Mas ele nao quis dizer que salva no banco para futuras consultas? Dependendo do SGDB, não é limitado.
darlan_machado
SGBD utiliza o filesystem… Em algum momento, o espaço para armazenar acaba.
Sem falar da concorrência no insert…
E se o objetivo é, unicamente, apresentar quando o usuário clica no “Visualizar”, basta gerar on demand, quando é necessário. Pronto.
javaflex
Tudo no final é filesystem, independente dos meios. Esse limite vai ser do “disco”, não do banco. Podem ter n tablespaces, cada um em um disco/local. Se for necessário, uma única tabela de blobs em um tablespace. Sobre os gargalos concordo, mas como falei na outra mensagem, depende dos requisitos, aqui o mais prioritário é a integridade/transação, não é sistema tipo facebook.
darlan_machado
Justamente. Mas, tudo isso acaba em limitações a serem consideradas.
Além disso, o que ele colocou não esclarece se estes arquivos serão gerados e gravados e ficarão lá eternamente ou serão excluídos a cada período de tempo.
javaflex
Também cheguei a imaginar que ele gerava um relatório em PDF, neste caso nao precisaria armazenar em lugar nenhum, mas parece não ser o caso.
I
igoorsp
O seguinte, melhor eu explicar o funcionamento rapidamente…
É um sistema de advocacia, então o advogado(no caso sera o “admin”) pode criar um cliente e um processo…
O processo só existe quando tem um cliente para ele vincular. Então eu preciso deixar armazenado esse arquivo no banco (seria o processo em PDF), pois toda vez que o cliente quiser consultar, vai estar disponível…
darlan_machado
Ok, entendi o cenário.
Porém, ainda penso que o mais adequado é você manter os dados do processo no banco e, quando necessário, gerar o PDF a partir deles.
Mas, é uma opção fazer conforme você precisa.
De qualquer forma, você só precisa ler o BLOB: