O esquema que só vive na base de dados em funcionamento

Tudo o que este serviço faz está em controlo de versões. O código, pelo menos. A base de dados sobre a qual corre são 32 tabelas, e 15 delas não têm definição em parte nenhuma do repositório — nenhum CREATE TABLE, nenhum ficheiro de esquema, nada. Se o servidor se perdesse, o código voltaria exacto e a forma dos dados teria de ser reconstruída a partir daquilo que o código calha pedir.

Estes números vêm de comparar a base em funcionamento com 736 ficheiros e 5.671.710 caracteres de repositório. Não são uma estimativa.

Como se perde meio esquema

Não é desleixo, e é isso que o torna digno de registo. Cada passo, isolado, foi razoável.

As tabelas criadas antes do código actual nunca foram escritas, porque na altura estavam simplesmente lá. As tabelas acrescentadas desde então chegaram por scripts de migração, e esses estão no repositório — daí vêm as 17 definições. As colunas acrescentadas mais tarde chegaram com um ALTER TABLE de uma linha escrito numa consola, porque escrevê-lo era mais rápido do que redigir um script para uma mudança que demora um segundo.

Os índices são o pior caso. Um índice acrescenta-se quando alguma coisa está lenta, no momento em que está lenta, e resolve logo. Não fica atrás nenhum artefacto, nada para rever, nada que falhe se nos esquecermos. Onze dos trinta e dois índices secundários daqui existem exactamente por isso e não estão registados em lado nenhum.

A tabela onde estão os próprios contadores, 166.438 linhas deles, é uma das quinze sem definição no repositório.

O que se parte de verdade

Pouco, até um momento concreto: quando a base é reposta a partir de uma cópia.

Uma cópia leva a estrutura, por isso uma reposição directa corre bem. O perigo é qualquer caminho que reconstrua uma tabela em vez de a repor — mudar para outra máquina, importar tabelas escolhidas, recriar uma a partir de um script. Os dados voltam e os índices, caladamente, não. Nada falha. As consultas devolvem as respostas certas. Só demoram mais, e a causa é invisível, porque o único registo do que o índice era está na máquina que já não o tem.

É esta a falha que vale a pena nomear: um índice em falta não produz um erro, produz uma resposta certa mais lenta. Não há teste para isso, porque os testes passam.

O que fazemos entretanto

A posição honesta é que isto não está resolvido. O esquema hoje não está no repositório. O que existe é menos do que uma solução e melhor do que nada:

Uma cópia antes de qualquer coisa destrutiva, guardada fora da raiz web. Uma reposição realmente feita pelo menos uma vez, em vez de presumida. E uma lista curta, verificada depois de cada reposição, dos índices que se sabe existirem só na base em funcionamento — porque à máquina pode perguntar-se que índices tem, e a resposta pode comparar-se com a da vez anterior.

A versão geral vale para mais do que bases de dados. Se uma parte do sistema está só no sistema em funcionamento, não se tem uma cópia dela, tem-se um refém. A pergunta que vale a pena fazer sobre qualquer peça de infra-estrutura não é «está salvaguardada» mas «se esta máquina desaparecesse, o que é que não podia ser reconstruído a partir do repositório». Aqui a resposta é quinze tabelas e onze índices, e descobri-lo levou uma tarde.