Mas desse modo você prende a aplicação ao Schema de banco de dados? Do modo como o marciorodr0 colocou não deixaria a aplicação mais portável?
R
romarcio
Com certeza dessa forma vai perder a portabilidade entre bancos diferentes.
Mas se for criar esse campo no banco pelo framework, dai para ter o tipo específico da coluna que você quer, precisa informa-lo na anotação Column.
Por exemplo, no MySQL temos 4 tipos de blob > TinyBlob, MediumBlob, Blob e LongBlob
Cada tipo armazena um dado com um tamanho (MB) diferente.
Se você usar apenas a anotação @Lob o framework vai escolher um tipo qualquer, acho que o Hibernate escolhe o Blob, mas se você precisa do LongBlob, ou precisa de um tamanho menor como o MediumBlob, teria que definir isso na anotação @Column.
H
Hebert_Coelho
romarcio:
Com certeza dessa forma vai perder a portabilidade entre bancos diferentes.
Mas se for criar esse campo no banco pelo framework, dai para ter o tipo específico da coluna que você quer, precisa informa-lo na anotação Column.
Por exemplo, no MySQL temos 4 tipos de blob > TinyBlob, MediumBlob, Blob e LongBlob
Cada tipo armazena um dado com um tamanho (MB) diferente.
Se você usar apenas a anotação @Lob o framework vai escolher um tipo qualquer, acho que o Hibernate escolhe o Blob, mas se você precisa do LongBlob, ou precisa de um tamanho menor como o MediumBlob, teria que definir isso na anotação @Column.
Mas desse modo você prende a aplicação ao Schema de banco de dados? Do modo como o marciorodr0 colocou não deixaria a aplicação mais portável?
Lá na empresa, tivemos uma série de problemas com o tipo LONG e a única solução foi usar JDBC puro para buscar os dados desse campo, já que outra aplicação (de terceiros) usa esse campo.
Se você puder substituir o campo LONG por CLOB (e LONG RAW por BLOB), é melhor, até porque a Oracle desaconselha o uso de LONG/LONG RAW desde 1997, com o lançamento do Oracle 8i.