Pular para o conteúdo
Tecnologia

Exportar do MySQL e voltar sem perder um dígito: o que o jsonW faz no caminho

Quando um dado sai do MySQL ou do MariaDB para um arquivo e volta, data sem fuso, código com zero à esquerda e inteiros enormes podem mudar. O wcon, do jsonW, leva os tipos do banco na ida e na volta, e o README mostra quais casos são cobertos e quais ainda pedem teste.

Por Equipe Wortic 9 min de leitura
Exportar do MySQL e voltar sem perder um dígito: o que o jsonW faz no caminho

Em 4 de novembro de 2026, a MariaDB anunciou a Enterprise Platform 2027, com o Enterprise Server 12.3. A empresa informou um pico de taxa de transferência 56% acima da versão 11.8, medido em testes patrocinados com os commits duráveis e o registro binário desativados. O número é do fornecedor e mostra a disputa por velocidade dentro do próprio banco. Este texto trata de outra parte do trabalho com dados: o que acontece com cada valor quando ele sai do banco para um arquivo e volta.

O problema começa no tipo, não na velocidade

Um banco relacional guarda cada coluna com um tipo: inteiro, decimal, data, texto. Quando o dado passa por JSON ou CSV, esse tipo some, e cada ferramenta decide de novo o que cada valor é. O README do jsonW dá três exemplos do estrago: o preço que vira texto, o CPF que perde o zero e o peso que ninguém sabe se era grama ou quilo.

A pergunta para quem decide não é só quanto tempo a exportação leva. É se o número que sai do arquivo é o mesmo que estava na tabela. Sem isso, o relatório da semana pode não bater com o sistema de origem, e a diferença costuma aparecer tarde.

O que o jsonW faz com os tipos do MySQL e do MariaDB

Segundo o README, o wcon lê o tipo de cada coluna do banco e escolhe o tipo do jsonW que guarda o valor sem perda. Pelo que está escrito no projeto, o mapeamento para MySQL e MariaDB funciona assim:

  • Números com casas decimais: numeric e decimal viram decimal exato, que nunca passa por ponto flutuante. Um valor de 12,50 continua 12,50.
  • Inteiros grandes: bigint continua inteiro de 64 bits. O BIGINT UNSIGNED acima de 2^63 vira texto, sem perder nenhum dígito.
  • Data e hora: DATE e DATETIME do MySQL e do SQLite ficam como texto, de propósito. Sem fuso no banco, virar meia-noite UTC poderia mudar o dia do registro.
  • Códigos: CNPJ, chave, placa e SKU vão como codigo, byte a byte. Não são normalizados nem aparados.

A escolha de manter data como texto parece um detalhe, mas é a que mais preserva o dado. Quem precisa converter depois faz isso com a regra da empresa, e não com a regra de um formato que não conhece o fuso do banco.

Como fica a ida e a volta, passo a passo

O exemplo abaixo está no README e leva uma tabela de pedidos do MySQL para um arquivo .jsw:

WMYSQL_CRED=~/.cred/mysql wcon mysql 127.0.0.1:3306/loja "select * from pedidos" pedidos.jsw

A senha fica num arquivo com usuário e senha, e não entra na linha de comando nem na URL. Para devolver os dados ao banco, o comando é wcon mysql-gravar, com o arquivo, o endereço do banco e o nome da tabela. Segundo o AGENTS.md do projeto, a volta acontece numa única transação, e qualquer erro desfaz tudo.

flowchart LR
    DB1[(MySQL ou MariaDB)] --> W1["wcon mysql"] --> F["arquivo .jsw"]
    F --> W2["wcon mysql-gravar"] --> DB2[(tabela de destino)]

O README afirma que o valor viaja sempre como dado, e nunca montado dentro de um comando. Nome de tabela e de coluna vai entre as aspas do próprio banco. Para quem revisa a segurança da integração, esse é um ponto para conferir no código que vai para produção.

Comparação honesta com o que se usa hoje

O caminho mais comum é exportar para CSV ou JSON e importar de volta. O AGENTS.md do jsonW desaconselha esse atalho, porque ele perde o tipo, o zero à esquerda e a precisão. O formato em colunas, o .jsw, troca essa conversão por um arquivo que guarda o tipo de cada coluna.

Também não é preciso trocar de banco. O README diz que o jsonW não pede essa troca: o wcon leva os dados para o arquivo e devolve do arquivo para o banco. O jsonW entra como o formato de guarda, transferência e consulta, ao lado do que já existe.

Espaço, velocidade e rede: o que está medido

Os números publicados pelo projeto são estes. O arquivo fica 4,9 vezes menor que o JSONL com os mesmos dados. A leitura de um campo de uma linha fica 3.281 vezes mais rápida. Os dois foram medidos com 100 mil registros, comparados com o JSONL lido pelo leitor de JSON do próprio projeto. Nas páginas lidas, não há medição contra o MySQL ou o MariaDB.

Essa diferença importa para quem decide. O README explica que bibliotecas de JSON mais otimizadas reduzem a diferença quando se grava e lê o arquivo inteiro. A vantagem de ler um campo específico vem do formato em colunas. Para medir na própria máquina, o comando é wjsw medir.

No caso de arquivos guardados em nuvem, o wremoto baixa só o cabeçalho, o rodapé e os blocos da pergunta. O README diz que, no Cloudflare R2, consultar um arquivo de 10 GB custa só o pedaço lido, porque o R2 não cobra pela saída de dados. Isso reduz o tráfego para consultas pontuais, mas não substitui um teste com o volume real da empresa.

Qualidade do dado: como provar que a volta ficou igual

O wjsw conferir verifica o arquivo inteiro com sha256 e crc32c, e aponta qualquer byte trocado. Para comparar duas versões de uma mesma tabela, o comando wjsw comparar ontem.jsw hoje.jsw id separa o que está só em um arquivo, o que está só no outro, o que mudou e o que ficou igual.

No teste publicado no README, a comparação foi feita com hex() em 12 colunas do MariaDB 11.8. Essa é a prova que vale copiar: escolha algumas colunas de risco, como data, código e inteiro grande, e compare antes e depois.

Autenticação do MySQL 8: um ponto para checar antes

O manual do MySQL 8.4 diz que caching_sha2_password é o plugin de autenticação padrão, e que mysql_native_password está deprecated. O README do jsonW registra que, por enquanto, o MySQL 8 entra só com mysql_native_password, porque a primeira autenticação completa do caching_sha2_password ainda não existe. O MariaDB funciona inteiro, segundo o mesmo README.

Antes de planejar o uso num MySQL 8, a equipe de TI deve verificar qual plugin usa cada conta que vai acessar o banco. Se a conta usa o padrão atual, a integração ainda não cobre esse caso.

Permissão dentro do arquivo

Quando o arquivo vai para mais de uma área da empresa, a permissão pode ficar no próprio esquema. O README traz o exemplo de uma coluna cpf:codigo?+pessoal, que só aparece para quem tem o escopo pessoal. Sem o escopo, a coluna sai nula e não pode ser usada em filtro. Assim, quem extrai o arquivo para análise não vê dado pessoal por acidente.

Liberdade funcional e licença

O núcleo é escrito em C, sem dependências, e a Licença de Uso Sustentável libera o uso no seu produto, em quantos servidores quiser. Não vale revender o jsonW como serviço nem fazer engenharia reversa do núcleo. O wcon roda em macOS e Linux. No Windows, o README indica o WSL.

Próximos passos para quem decide tecnologia

  • Liste as tabelas que hoje saem do MySQL ou do MariaDB em CSV ou JSON, e marque as que têm data sem fuso, código com zero à esquerda, inteiro acima de 2^63 ou valor monetário.
  • Faça a ida e a volta de uma tabela de teste e compare as colunas de risco com hex() antes e depois.
  • Rode wjsw medir e wjsw conferir na máquina que vai executar a rotina, antes de decidir.
  • Se o banco for MySQL 8, confirme o plugin de autenticação de cada conta.

Para conhecer o formato, leia a página do jsonW e o repositório no GitHub, que tem o README, o AGENTS.md e a licença.

Perguntas frequentes

Dá para exportar uma tabela do MySQL para um arquivo e voltar sem perder dados?

Segundo o README do jsonW, o wcon faz a ida e a volta sem perda, e a volta acontece numa única transação. A prova publicada cita o MariaDB 11.8, com hex() em 12 colunas. O MySQL 8 aparece só na nota sobre autenticação, então teste com a sua versão antes de usar em produção.

O jsonW substitui o MySQL ou o MariaDB?

Não. O jsonW não pede que você troque de banco. O wcon leva os dados do banco para um arquivo .jsw e devolve do arquivo para o banco.

Por que a data e a hora do MySQL ficam como texto?

Porque DATE e DATETIME sem fuso no banco não informam o fuso. Converter para UTC poderia mudar o dia do registro, então o jsonW mantém o valor como texto.

O que acontece com um BIGINT UNSIGNED muito grande?

Acima de 2^63 ele vira texto. Segundo o README, nenhum dígito se perde nessa conversão.

O jsonW é mais rápido que o MySQL?

As páginas lidas não trazem medição contra o MySQL. Os números publicados, de 4,9 vezes menos espaço e 3.281 vezes mais rapidez para ler um campo, comparam o jsonW com JSONL em 100 mil registros. Para medir na sua máquina, use o comando wjsw medir.

Preciso de Windows para usar o wcon?

O README diz que o wcon e o wremoto estão nos binários de macOS e Linux. No Windows, a indicação é rodá-los pelo WSL.

Como guardar a senha do banco com segurança?

Em um arquivo com usuário e senha, apontado pela variável WMYSQL_CRED. Segundo o README, a senha nunca entra na linha de comando nem na URL.

Posso usar o jsonW de graça dentro da minha empresa?

A Licença de Uso Sustentável libera o uso no seu produto, em quantos servidores quiser. Não vale revender o jsonW como serviço nem fazer engenharia reversa do núcleo. Leia a licença completa antes de decidir.

Fontes

Conheça: jsonW com MySQL e MariaDB.

Quer isso funcionando na sua empresa?

Um consultor da Wortic olha o seu caso e mostra o caminho, sem compromisso.

Falar com um consultor

Equipe editorial

Equipe editorial da Wortic especializada em automacao, IA, ERP, CRM e crescimento operacional.

  • Automacao com IA
  • Gestao empresarial
  • CRM
  • ERP
  • Marketing digital

Isso funcionando no seu negócio.

Um consultor mostra o sistema do seu ramo, com a IA dentro.