Modifier un moteur de bases de données analytiques en C++ et réussir ses tests

## Choisir le type de compilation et les tests pour chaque étape Choisissez une configuration de compilation qui fournisse des assertions et des diagnostics pertinents sans ralentir inutilement les itérations courantes. ### Stratégie de compilation - Utilisez une compilation optimisée avec symboles de débogage comme configuration normale de développement lorsqu’elle conserve les contrôles requis. - Utilisez une compilation de débogage entièrement instrumentée lorsque vous étudiez la sûreté de la mémoire, des échecs d’assertion ou un comportement que l’optimisation pourrait modifier. - Exécutez l’outil de formatage du dépôt avant toute validation. - Régénérez les fichiers dérivés des sources au moyen de la cible de génération approuvée, qui doit également appliquer le formatage requis. ### Stratégie de test - Exécutez la suite rapide de tests unitaires pendant les itérations normales. - Limitez une exécution à un fichier ou un cas de test lorsque vous diagnostiquez une modification ciblée. - Exécutez la suite complète, y compris les tests lents, avant un transfert étendu lorsque la modification peut affecter un comportement partagé. - Lorsque vous corrigez des échecs d’intégration continue, reproduisez chaque configuration requise dans l’ordre documenté. - Incluez les compilations de matrice de configurations, d’exécution vectorisée, avec assainisseurs et avec assertions lorsque la frontière concernée les exige. - Ne remplacez pas une étape de contrôle faisant autorité qui échoue par une configuration locale plus rapide sans preuve que la différence est sans incidence. ## Avant de corriger, suivre la requête de l’analyse SQL jusqu’aux résultats Retracez le comportement sur l’ensemble du cycle de vie de la requête au lieu de corriger uniquement le premier module qui révèle un symptôme. ### Étapes du pipeline 1. Analysez le texte SQL pour produire des arbres syntaxiques d’instructions, d’expressions et de références de tables. 2. Liez les noms et les types au catalogue tout en créant un plan logique. 3. Optimisez le plan logique avec des règles qui préservent la sémantique et des choix fondés sur les coûts. 4. Convertissez les opérateurs logiques en opérateurs physiques. 5. Exécutez les opérateurs physiques au moyen de pipelines vectorisés et parallèles. 6. Renvoyez les résultats par l’intermédiaire de la connexion et du contexte client. ### Propriété des composants - Maintenez la grammaire et les transformations de l’analyseur synchronisées ; chaque règle de grammaire nécessite la transformation correspondante. - Confiez au planificateur la liaison, la résolution des types, les sous-requêtes et les opérateurs logiques. - Laissez l’optimiseur transformer les plans sans modifier la sémantique observable. - Confiez à la couche d’exécution la planification physique, les opérateurs et l’évaluation des expressions. - Conservez le stockage persistant, la mise en mémoire tampon, la compression, les points de contrôle et la journalisation avant écriture dans la couche de stockage. - Traitez le catalogue comme l’unique source de vérité pour les schémas, les tables, les fonctions et les types. - Séparez les transactions, l’état d’annulation et le contrôle de concurrence multiversion de l’ordonnancement des tâches et des pipelines parallèles. ## Traiter les données par lots de colonnes et respecter les règles de propriété Un moteur analytique repose sur des distinctions claires entre la syntaxe analysée, les expressions liées, l’identité des colonnes, les vecteurs physiques et la propriété. ### Flux de données - Traitez les données en lots orientés colonnes plutôt qu’une ligne à la fois. - Représentez chaque colonne d’un lot avec l’abstraction vectorielle du moteur. - Transmettez une paire stable d’index de table et de colonne tout au long de la planification et de l’exécution. - Conservez les expressions analysées non liées et séparées des expressions typées et liées. - Évaluez les expressions liées avec l’exécuteur vectorisé d’expressions. ### Propriété et types - Utilisez par défaut une propriété intelligente exclusive. - N’utilisez la propriété partagée que lorsque plusieurs durées de vie l’exigent réellement. - Distinguez les références non propriétaires pouvant être nulles des références garanties non nulles. - N’utilisez jamais de pointeurs bruts propriétaires. - Faites passer la promotion de types et les conversions par un seul ensemble de règles faisant autorité. - Ajoutez des types personnalisés au moyen du mécanisme d’extension plutôt que de contourner le système de types. - Utilisez des visiteurs pour parcourir les arbres, des fabriques pour la désérialisation et des sous-classes typées pour les hiérarchies d’opérateurs, d’entrées et d’expressions. ## Modifier les extensions et les fichiers générés depuis leurs sources Traitez les extensions intégrées à l’arborescence, les extensions maintenues en externe, le code généré et les artefacts de publication comme des catégories de propriété différentes. ### Frontières des extensions - Modifiez directement les extensions intégrées à l’arborescence dans leur répertoire source déclaré. - Conservez les extensions maintenues en externe dans des dépôts séparés et appliquez les modifications appartenant au dépôt au moyen du mécanisme de correctifs désigné. - Prenez en charge la compilation de l’ensemble complet des extensions ou d’un sous-ensemble explicite. - Testez les modifications d’extensions avec les mêmes interfaces principales et règles de types que les fonctionnalités intégrées. ### Artefacts générés - Identifiez les fichiers source qui génèrent les liaisons d’API, les enregistrements, les paramètres, le code de sérialisation, les métadonnées de stockage, les métriques et les utilitaires d’énumération. - Modifiez la source d’un artefact généré, jamais uniquement sa sortie générée. - Exécutez la cible de génération approuvée après toute modification des sources. - Examinez les différences générées afin de détecter les changements sans rapport et formatez-les avec l’outil standard. ## Suivre le style C++ et garder des commentaires courts La cohérence du code de bas niveau réduit l’ambiguïté concernant la propriété, les index, les interfaces publiques et le flux de contrôle. ### Style du code - Utilisez les règles d’indentation et d’alignement du dépôt et faites respecter sa limite de largeur de ligne avec l’outil de formatage. - Préférez les types entiers de largeur fixe aux largeurs d’entiers dépendantes de la plateforme. - Utilisez le type d’index désigné par le projet pour les décalages, les index et les décomptes. - Passez les objets non triviaux en lecture seule par référence constante. - Préférez les boucles basées sur une plage lorsqu’elles expriment clairement le parcours. - Utilisez toujours des accolades pour les conditions et les boucles. - N’utilisez jamais `const_cast`. - Respectez les conventions établies de nommage des fichiers, des types, des variables et des fonctions. ### Commentaires - Gardez les commentaires courts et laissez un code clair fournir les explications ordinaires. - Commentez les intentions durables, les contraintes ou les invariants non évidents. - Ne laissez pas dans le code l’historique d’une correction propre à un problème. - Placez le récit des modifications, comme la correction d’un décalage d’une unité, dans la description de la modification ou le message de validation. - N’utilisez des commentaires plus longs que lorsque la structure et le nommage du code ne peuvent pas rendre l’invariant clair. ## Choisir exceptions ou assertions selon l’erreur et écrire des tests de logique SQL Choisissez les canaux d’erreur selon qu’une requête doit s’arrêter, peut récupérer ou a rencontré un défaut interne de programmation. ### Politique d’erreur - Utilisez des exceptions pour les défaillances qui mettent fin à la requête, comme les erreurs d’analyse, les objets absents ou l’épuisement de la mémoire. - Utilisez des valeurs de retour pour les conditions récupérables pendant la même requête. - Utilisez des assertions de débogage pour les erreurs de programmation que les entrées utilisateur ne doivent jamais déclencher. - Rendez les assertions suffisamment précises pour révéler l’invariant enfreint. - Ne transformez pas une entrée non valide attendue en échec d’assertion interne. ### Tests logiques SQL - Préférez les tests logiques SQL déclaratifs aux tests C++ pour le comportement des requêtes. - Marquez séparément les instructions qui doivent réussir et celles qui doivent échouer. - Déclarez les types attendus des colonnes de résultats pour les requêtes. - Séparez le texte de la requête des lignes attendues avec le délimiteur canonique du cadre logiciel. - N’utilisez des attentes par expression régulière pour le texte des erreurs que lorsque la formulation exacte est volontairement instable. - Déclarez explicitement les variables d’environnement requises. - Attribuez aux tests lents la désignation correspondante du cadre logiciel afin que les exécutions par défaut restent pratiques. - Couvrez les types numériques, les chaînes et les types imbriqués, ainsi que les utilisations non valides et inattendues, plutôt que le seul cas favorable. - Exigez la réussite de la suite complète faisant autorité avant la soumission. ## Trouver quoi modifier grâce aux tests et finir toutes les vérifications nécessaires Utilisez les tests et la propriété architecturale pour localiser une fonctionnalité avant de la modifier, puis vérifiez chaque surface dérivée affectée par la modification. ### Séquence d’investigation 1. Recherchez les tests existants pour connaître la syntaxe prise en charge et le comportement attendu. 2. Suivez la fonctionnalité de l’analyseur jusqu’à l’exécution en passant par le lieur, l’optimiseur et la planification physique. 3. Localisez les types d’instruction, d’opérateur, d’expression, de catalogue ou de fonction correspondants. 4. Vérifiez où la fonctionnalité est enregistrée et où réside sa déclaration publique. 5. Recherchez les fichiers d’implémentation et les en-têtes publics avec l’outil standard de recherche de code du dépôt. 6. Identifiez les fichiers générés et les surfaces d’extension qui dépendent de la source modifiée. ### Contrôles d’achèvement - Ajoutez ou mettez à jour des tests de régression ciblés avant les tests étendus. - Exécutez le formatage et la génération depuis les sources. - Exécutez le test ciblé, puis les suites requises de tests unitaires, lents, avec assainisseurs, d’assertions, de configurations et de vecteurs. - Compilez l’exécutable et les extensions concernés. - Examinez les différences générées et la propriété de la documentation. - Ne déclarez pas l’achèvement tant que chaque étape de contrôle requise n’a pas produit un résultat réel.