Re: MODERAÇÃO: Insert em campo blob do MySQL

[Cristiano Ferrari]

--- Em address@hidden, MrBiTS <mrbits@...> escreveu
> Até onde sei, Shell-Script, de per si, não tem ferramentas 
> para tratamento de campos BLOB.
> E, MySQL por MySQL, ainda mais com tratamentos de campos BLOB,
> foge do escopo da lista.
> Entretanto, SE a lista achar pertinente e a moderação ver que 
> a coisa não destrambelhou, por ser uma informação interessante, 
> vamos deixá-la seguir, sempre atentos para a ordem das coisas

Carrísimo MrBiTs...

Entendo que o post possa ser off topic. My bad!

Porém, já que é quase sexta e seu coração parece ficar mais mole
quanto mais o sábado se aproxima, me permita atualizar o assunto antes
de encerrar a thread.

Quanto ao problema do MySQL, assunto resolvido:

<offtopic>
Pesquisei um pouquinho e descobri que para inserir um arquivo em um
campo blob, usa-se a função LOAD_FILE do próprio MySQL. A sintaxe é
simples:

mysql> insert into tabela (mblob_row) values (LOAD_FILE('/tmp/file.bin'))

E, **em tese**, para extrair, há dois caminhos (há um pouco de shell
aqui):

1. usando a função outfile 

# echo "select mblob_row from tabela where id = $CHAVE into outfile
'/tmp/file_out.bin'" | mysql -u$USER -p$PASSWORD -h$HOST -D$BANCO

ou 

2. via stdout com um redicionador

# echo "select mblob_row from tabela where id = $CHAVE" | mysql --raw
--skip-column-names -u$USER -p$PASSWORD -h$HOST -D$BANCO >
/tmp/file_out.bin

No segundo caso, as chaves --raw e --skip-column-names são
necessárias, como os próprios nomes sugerem, para manter os dados como
foram inseridos (sem a interpretação dos caracteres escape) e suprimir
da saída o nome da coluna.
</offtopic>

Bom, daqui pra frente acho que o assunto passa a ser shell.

Isto pois, a solução acima, em tese, **deveria** funcionar
perfeitamente, mas não funciona.

Em ambos os modos, a saída não é idêntica à entrada e o arquivo de
saída fica corrompido. No primeiro caso, a cada quebra de página o
MySQL acrescenta um caracter de "\" (descobri isso testando com um
arquivo texto), deturpando o conteúdo do arquivo. Acrescentar a opção
--raw no comando mysql, não resolve o problema.

No segundo caso, devidamente respeitadas as opções --raw e
--skip-column-names, o conteúdo de saída é quase idêntico ao de
entrada, exceto pelo fato de que é acrescido uma quebra de linha ao
fim do arquivo.

Daí, penso que possa entrar o shell. 

Para o primeiro método, eu não consegui solução (e concordo que o
assunto talvez seja mesmo tema para uma lista de mysql e não de shell).

Mas para o segundo caso eu consegui contornar a questão com um
"recurso técnico": já que o MySQL acrescenta uma nova linha no fim do
arquivo, basta, ao recuperá-lo, remover esta linha. 

OK, isso funciona perfeitamente para textos, mas, e para binários? 

Bom, eu usei outro "recurso técnico" e codifiquei o conteúdo do
arquivo em base64 (via openssl) antes do fazer o insert na base. Na
hora de recuperar o conteúdo, sendo texto, eu removi a última linha e
decodifiquei de volta. 

Funcionou.

O problema é que, para os meus padrões (e acredito que para os
vossos), estes "recursos" são gambiarras.

Mas... entendo que o assunto já foge ao escopo da lista.

Se alguém tem experiência no assunto e quiser me ajudar, por favor,
faça em PVT (mas, por favor, *faça*). Quando a gente resolver o
problema, contamos o caminho das pedras sem poluir a lista.

Abraço, boa noite e obrigado pela compreensão.