Altere um mecanismo de banco de dados analítico em C++ e passe nos testes

## Escolha o tipo de compilação e os testes para cada etapa Escolha uma configuração de compilação que forneça asserções e diagnósticos relevantes sem tornar a iteração rotineira desnecessariamente lenta. ### Estratégia de compilação - Use uma compilação otimizada com símbolos de depuração como configuração normal de desenvolvimento quando ela preservar as verificações necessárias. - Use uma compilação de depuração totalmente instrumentada ao investigar segurança de memória, falhas de asserção ou comportamentos que a otimização possa afetar. - Execute o formatador do repositório antes de confirmar alterações. - Regenere os arquivos derivados do código-fonte por meio do alvo de geração aprovado, que também deve aplicar a formatação necessária. ### Estratégia de testes - Execute a suíte rápida de testes unitários durante a iteração normal. - Restrinja uma execução a um arquivo ou caso de teste ao diagnosticar uma alteração específica. - Execute a suíte completa, incluindo os testes lentos, antes de uma entrega ampla quando a alteração puder afetar o comportamento compartilhado. - Ao corrigir falhas de integração contínua, reproduza cada configuração necessária na ordem documentada. - Inclua compilações de matriz de configurações, execução vetorizada, sanitizadores e asserções quando o limite afetado as exigir. - Não substitua um controle autoritativo com falha por uma configuração local mais rápida sem evidências de que a diferença é irrelevante. ## Antes de corrigir, siga a consulta da análise do SQL até os resultados Rastreie o comportamento por todo o ciclo de vida da consulta, em vez de corrigir apenas o primeiro módulo que apresenta um sintoma. ### Etapas do fluxo 1. Analise o texto SQL em árvores sintáticas de instruções, expressões e referências de tabelas. 2. Vincule nomes e tipos ao catálogo enquanto cria um plano lógico. 3. Otimize o plano lógico com regras que preservem a semântica e escolhas baseadas em custo. 4. Converta operadores lógicos em operadores físicos. 5. Execute operadores físicos por meio de fluxos vetorizados e paralelos. 6. Retorne os resultados pela conexão e pelo contexto do cliente. ### Propriedade dos componentes - Mantenha sincronizadas a gramática e as transformações do analisador; toda regra gramatical precisa da transformação correspondente. - Faça o planejador controlar a vinculação, a resolução de tipos, as subconsultas e os operadores lógicos. - Faça o otimizador transformar os planos sem alterar a semântica observável. - Faça a camada de execução controlar o planejamento físico, os operadores e a avaliação de expressões. - Mantenha o armazenamento persistente, o uso de buffers, a compactação, os pontos de verificação e o registro antecipado de gravação na camada de armazenamento. - Trate o catálogo como a única fonte da verdade para esquemas, tabelas, funções e tipos. - Mantenha as transações, o estado de desfazer e o controle de concorrência multiversão separados do agendamento de tarefas e dos fluxos paralelos. ## Processe os dados em lotes de colunas e siga as regras de propriedade Um mecanismo analítico depende de distinções claras entre a sintaxe analisada, as expressões vinculadas, a identidade das colunas, os vetores físicos e a propriedade. ### Fluxo de dados - Processe os dados em lotes colunares, em vez de uma linha por vez. - Represente cada coluna do lote com a abstração vetorial do mecanismo. - Mantenha um par estável de índices de tabela e coluna durante o planejamento e a execução. - Mantenha as expressões analisadas sem vinculação e separadas das expressões tipadas e vinculadas. - Avalie as expressões vinculadas por meio do executor vetorizado de expressões. ### Propriedade e tipos - Use propriedade inteligente exclusiva por padrão. - Use propriedade compartilhada apenas quando vários tempos de vida realmente a exigirem. - Diferencie referências não proprietárias anuláveis de referências com valor não nulo garantido. - Nunca use ponteiros brutos que sejam proprietários. - Encaminhe a promoção de tipos e as conversões por um único conjunto autoritativo de regras. - Adicione tipos personalizados por meio do mecanismo de extensões, em vez de contornar o sistema de tipos. - Use visitantes para percorrer árvores, fábricas para desserialização e subclasses tipadas para hierarquias de operadores, entradas e expressões. ## Edite extensões e arquivos gerados a partir do código-fonte Trate extensões internas da árvore, extensões mantidas externamente, código gerado e artefatos de lançamento como classes de propriedade distintas. ### Limites das extensões - Edite diretamente as extensões internas da árvore no diretório de origem declarado. - Mantenha as extensões administradas externamente em repositórios separados e aplique alterações pertencentes ao repositório pelo mecanismo de patches designado. - Permita compilar tanto o conjunto completo de extensões quanto um subconjunto explícito. - Teste alterações de extensões com as mesmas interfaces centrais e regras de tipos usadas pela funcionalidade integrada. ### Artefatos gerados - Identifique os arquivos-fonte que geram vinculações de API, registros, configurações, código de serialização, metadados de armazenamento, métricas e utilitários de enumeração. - Edite a origem de um artefato gerado, nunca apenas sua saída gerada. - Execute o alvo de geração aprovado depois de alterar o código-fonte. - Examine as diferenças geradas em busca de alterações não relacionadas e formate-as com o formatador padrão. ## Siga o estilo de C++ e mantenha os comentários curtos A consistência no código de baixo nível reduz ambiguidades relacionadas à propriedade, aos índices, às interfaces públicas e ao fluxo de controle. ### Estilo de código - Use as regras de indentação e alinhamento do repositório e imponha seu limite de largura de linha com o formatador. - Prefira tipos inteiros de largura fixa a larguras inteiras dependentes da plataforma. - Use o tipo de índice designado pelo projeto para deslocamentos, índices e contagens. - Passe objetos não triviais somente de leitura por referência constante. - Prefira laços baseados em intervalos quando expressarem claramente o percurso. - Sempre use chaves em condicionais e laços. - Nunca use `const_cast`. - Siga as convenções estabelecidas de nomenclatura de arquivos, tipos, variáveis e funções. ### Comentários - Mantenha os comentários curtos e deixe o código claro fornecer a explicação comum. - Comente intenções duradouras, restrições ou invariantes não óbvios. - Não deixe no código o histórico de correções específico de um problema. - Coloque narrativas de alterações, como uma correção de diferença de uma posição, na descrição da alteração ou na mensagem de confirmação. - Use comentários mais longos somente quando o invariante não puder ficar claro pela estrutura e pelos nomes do código. ## Escolha exceções ou asserções pelo tipo de erro e escreva testes de lógica SQL Escolha os canais de erro de acordo com a necessidade de a consulta terminar, poder se recuperar ou ter encontrado um defeito interno de programação. ### Política de erros - Use exceções para falhas que encerram a consulta, como erros de análise, objetos ausentes ou memória esgotada. - Use valores de retorno para condições das quais seja possível se recuperar durante a mesma consulta. - Use asserções de depuração para erros de programação que a entrada do usuário nunca deva provocar. - Torne as asserções específicas o bastante para revelar o invariante violado. - Não transforme uma entrada inválida esperada em uma falha interna de asserção. ### Testes lógicos de SQL - Prefira testes lógicos declarativos de SQL a testes de C++ para o comportamento das consultas. - Marque separadamente as instruções que devem ser bem-sucedidas e as que devem falhar. - Declare os tipos esperados das colunas de resultados das consultas. - Separe o texto da consulta das linhas esperadas com o delimitador canônico da estrutura. - Use expectativas de expressões regulares para textos de erro somente quando a redação exata for intencionalmente instável. - Declare explicitamente as variáveis de ambiente necessárias. - Atribua aos testes lentos a designação de teste lento da estrutura para que as execuções padrão continuem práticas. - Cubra tipos numéricos, de cadeia e aninhados, além de usos inválidos e inesperados, em vez de apenas o caminho bem-sucedido. - Exija que a suíte autoritativa completa seja aprovada antes do envio. ## Encontre o que mudar pelos testes e conclua todas as verificações necessárias Use os testes e a propriedade arquitetural para localizar uma funcionalidade antes de editá-la e, depois, verifique cada superfície derivada afetada pela alteração. ### Sequência de investigação 1. Encontre testes existentes para conhecer a sintaxe compatível e o comportamento esperado. 2. Rastreie a funcionalidade desde o analisador, passando pelo vinculador, pelo otimizador e pelo planejamento físico, até a execução. 3. Localize os tipos correspondentes de instrução, operador, expressão, catálogo ou função. 4. Verifique onde a funcionalidade é registrada e onde fica sua declaração pública. 5. Pesquise arquivos de implementação e cabeçalhos públicos com a ferramenta padrão de busca de código do repositório. 6. Identifique os arquivos gerados e as superfícies de extensão que dependem do código-fonte alterado. ### Verificações de conclusão - Adicione ou atualize testes de regressão específicos antes de realizar testes amplos. - Execute a formatação e a geração a partir do código-fonte. - Execute o teste específico e, depois, as suítes necessárias de testes unitários, lentos, de sanitizadores, asserções, configurações e vetores. - Compile o executável e as extensões afetados. - Revise as diferenças geradas e a propriedade da documentação. - Não declare a conclusão até que todo controle necessário tenha um resultado real.