Arquitetura¶
Esta página descreve a arquitetura implementada no código atual do GitDatabase.
Como ler esta documentação¶
- Contexto e componentes: fronteiras, processos, crates, topologias e segurança
- Pipelines e consistência: ciclo de vida dos dados, idempotência e recuperação
- Atributos de qualidade: riscos de produção, capacidade, segurança e estratégia de testes
- Banco de dados: modelo relacional, índices e consultas
- Plano de funcionalidades: lacunas priorizadas e critérios de aceite
Princípios implementados¶
- PostgreSQL como plataforma de dados: persistência, busca e consultas usam capacidades nativas do banco.
- Conteúdo endereçado por hash: blobs, índice textual e UAST são deduplicados por SHA-1 do objeto Git.
- Ingestão em estágios: metadata, conteúdo, busca e semântica podem evoluir e ser reexecutados separadamente.
- Git permanece fonte de verdade: o banco é uma projeção consultável; a hidratação ainda depende dos objetos locais.
- Limites antes de parsing: tamanho, binário e UTF-8 protegem os estágios de conteúdo.
Workspace e crates¶
O projeto é um workspace Rust com os seguintes crates:
gitbase-cli: interface de linha de comando e orquestração dos fluxosgitbase-db: conexão com PostgreSQL, migrações e acesso a dadosgitbase-git: leitura de repositórios Git comgixgitbase-loader: pipeline de ingestão/indexaçãogitbase-uast: parsing semântico (Go/Rust) via tree-sittergitbase-pgwire: servidor compatível com protocolo PostgreSQL
Comandos da CLI¶
Comandos disponíveis em gitbase-cli:
serve: sobe servidor pgwiresync: sincroniza metadados Githealth: checa conectividade e migraçõeshydrate-blobs: hidrata conteúdo textual dos blobssearch-index: monta/atualiza índice de busca textualuast: gera cache/projeções de UAST
Fluxo de dados¶
Repositórios Git
↓ (gitbase-git)
Metadados (repos/refs/commits/tree/files)
↓ (gitbase-loader + gitbase-db)
PostgreSQL (schema gitbase)
↓
Blobs hidratados + índice de busca + UAST
↓
Consultas SQL / pgwire
O pipeline é eventualmente consistente: concluir sync não implica que blobs,
busca ou UAST estejam atualizados. Consulte a
matriz de reexecução.
Detalhes de implementação relevantes¶
1) Descoberta e leitura Git (gitbase-git)¶
- Usa
gixpara abrir repositórios e caminhar histórico - Suporta roots com
.git/e repositórios bare - Gera snapshots de commit contendo:
- metadados do commit
- entradas de árvore
- arquivos por commit
- Classifica blobs binários por NUL byte e validação UTF-8
2) Sincronização (gitbase-loader::sync_repositories)¶
- Faz upsert em:
repositoriesrefscommitscommit_parentstree_entriesfiles- Evita retrabalho para commits já persistidos
3) Hidratação de blobs (hydrate_blobs / hydrate_missing_blobs)¶
- Busca blobs faltantes no banco
- Lê blob no Git de origem
- Regras:
- blob maior que
max_blob_bytes→ marca sem conteúdo - blob binário → marca sem conteúdo
- blob textual válido → persiste
content
4) Indexação de busca (index_search)¶
- Candidatos vêm de
files+blobs - Só indexa conteúdo textual UTF-8
- Normaliza NUL (
\0) para espaço - Persiste
tsvectoremcode_index
5) Indexação UAST (index_uast)¶
- Suporta linguagens detectadas por extensão:
.go.rs- Armazena documento UAST em JSONB (
uast_cache) - Projeta funções e imports em tabelas específicas
6) Consulta via pgwire (gitbase-pgwire)¶
- Server escuta em
bind(default0.0.0.0:5433) - Autenticação simples por usuário/senha configuráveis
- Encaminha queries para PostgreSQL real (
sqlx) - Em consultas
SELECT, tenta hidratar blobs referenciados porblob_hashantes de executar
Invariantes e limites¶
repositories.pathé único e também participa indiretamente da identidade do repositório.- commits, files e tree entries pertencem a um repositório lógico, mas essa relação ainda não é protegida por foreign keys.
filesrepresenta ocorrências por commit; não é uma visão apenas do HEAD.blobs,code_indexeuast_cachesão globais por hash.- uma linha em
blobscomcontent IS NULLpode representar binário, objeto acima do limite ou hidratação ainda pendente. - a implementação atual não reconcilia deleções e force-pushes.
- o listener pgwire usa autenticação cleartext e deve permanecer em rede protegida.
Decisões que ainda precisam de ADR¶
- identidade estável do repositório: path, remote URL ou UUID;
- retenção de histórico após refs deixarem de alcançar commits;
- atomicidade por commit versus por repositório;
- versionamento e invalidação dos caches search/UAST;
- exposição do pgwire como gateway administrativo ou somente leitura.
Variáveis de ambiente mais usadas¶
DATABASE_URLGITBASE_REPO_ROOTSGITBASE_DB_MAX_CONNECTIONSGITBASE_BLOB_MAX_BYTESGITBASE_BLOB_HYDRATE_LIMITGITBASE_SEARCH_LIMITGITBASE_UAST_LIMITGITBASE_BIND_ADDRGITBASE_PG_USERGITBASE_PG_PASSWORD
Estado de maturidade¶
O projeto implementa um pipeline funcional e possui testes unitários, integração com PostgreSQL e um cenário E2E em containers. Antes de produção multiusuário, as prioridades são consistência transacional, reconciliação, integridade referencial, alinhamento do toolchain e endurecimento do pgwire. A ordem proposta está no roadmap.