E ai galera, blz ?
entao, tenho que fazer um cadastra de cliente ( usando o NetBeans ) so q nesse cadastro tenho que colocar a foto do individuo…aff
e ainda tenho q usar o hibernate…
alguem tem alguma ideia de como fazer isso?
valeuuuuuuuuuu
ha … o cadastro basico em hibernate nao é o problema…o problema é a foto
se vc achar a resposta, posta aqui, pq eu tb to precisando fazer isto
Se for código anotado, vc pode usar a anotação @Lob
“@Lob indicates that the property should be persisted in a Blob or a Clob depending on the property type: java.sql.Clob, Character[], char[] and java.lang.String will be persisted in a Clob. java.sql.Blob, Byte[], byte[] and serializable type will be persisted in a Blob.”
Vc deve estar armazenando a foto como um tipo byte[]… Então basta anotar como @Lob que o Hibernate cuida do resto
@Lob
public byte[] getImagem() {
return image;
}
Verifica se você reamente precisa persistir a imagem no banco de dados.
As vezes é melhor a base só apontar o caminho.
[]'s
Esse é um tema polêmico. Existem aqueles que defendem o uso do sistema de arquivos, enquanto outros defendem o uso do banco de dados.
Eu particularmente tenho a seguinte posição: Armazenar os arquivos no banco de dados traz algumas facilidades pra aplicação.
Integridade relacional… Estando o arquivo como um campo de uma tabela você garante a consistência. Você não corre o risco, por exemplo, do banco de dados estar apontando para “arquivo.jpg” e o arquivo tenha sido apagado do sistema de arquivos.
Permissões de leitura/escrita. Você usa todo o controle de permissões que o SGBD te fornece. Utilizando o sistema de arquivos você precisará realizar todo o processo de controle de permissões no sistema de arquivos. Se você puder manter tudo isso centrado no SGBD a manutenção do sistema fica mais fácil.
Commits e Rollbacks. Utilizando o SGBD você pode fazer um controle transacional mais adequado. Não corre o risco, por exemplo, de que dados tenham sido registrados no banco de dados e enquanto o arquivo está sendo escrito no sistema de arquivos ocorra algum problema (como queda de energia) o que pode gerar uma inconsistência, já que o teu banco de dados aponta para um arquivo inexistente ou incompleto. Utilizando o controle do banco de dados fica mais fácil manter a consistência do sistema, já que o commit pode ser efetuado quando toda a transação esteja completa. Além disso você não corre o risco de que um usuário tente acessar um arquivo que ainda esteja em processo de escrita, evitando assim erros na exibição deste.
UPDATE e DELETE. Você tem meios fáceis para atualizar ou apagar o arquivo caso esteja armazenado no banco de dados. Caso esteja no sistema de arquivos será necessário você fazer uma chamada do sistema para que o arquivo seja apagado ou alterado. Além disso evita erros na exibição do arquivo no caso do usuário estar acessando o arquivo no momento em que este está sendo apagado.
Em virtude desses e de outros fatores eu acho mais recomendável manter os dados armazenados no banco de dados. Além disso existe uma lenda de que os arquivos tornem o banco de dados “pesado”. Caso os índices estejam bem construídos e não sejam executadas consultas no conteúdo dos arquivos, a velocidade nas consultas não será prejudicada caso os arquivos estejam armazenados no banco. A maioria dos SGBDs não mantém o conteúdo de campos BLOB alocados previamente. Quando existe um campo BLOB em uma tabela, na verdade o arquivo não está inserido diretamente na tupla. Existe um ponteiro na tabela que aponta pro endereço fisico do arquivo. Desta forma o número de acessos a disco na recuperação de determinado número de tuplas não será prejudicado pelos arquivos.
Opiniões a respeito do assunto são bem vindas…
Abraços
Não tenho tréplica! haha
Motivou muito bem! 
Valeu!
[]'s