Eine analytische Datenbank-Engine in C++ ändern und die nötigen Tests bestehen

## Für jede Arbeitsphase Build-Art und Tests auswählen Wählen Sie eine Kompilierungskonfiguration, die aussagekräftige Zusicherungen und Diagnosen bereitstellt, ohne die regelmäßige Entwicklung unnötig zu verlangsamen. ### Kompilierungsstrategie - Verwenden Sie eine optimierte Kompilierung mit Debugsymbolen als normale Entwicklungskonfiguration, wenn dabei die erforderlichen Prüfungen erhalten bleiben. - Verwenden Sie eine vollständig instrumentierte Debugkompilierung, wenn Sie Speichersicherheit, fehlgeschlagene Zusicherungen oder möglicherweise optimierungsabhängiges Verhalten untersuchen. - Führen Sie vor dem Commit das Formatierungswerkzeug des Repositorys aus. - Erzeugen Sie aus Quelltext abgeleitete Dateien über das genehmigte Generierungsziel neu, das auch die erforderliche Formatierung anwenden sollte. ### Teststrategie - Führen Sie bei der normalen Entwicklung die schnelle Komponententestsammlung aus. - Beschränken Sie einen Testlauf auf eine Testdatei oder einen Testfall, wenn Sie eine gezielte Änderung untersuchen. - Führen Sie vor einer umfassenden Übergabe die vollständige Testsammlung einschließlich langsamer Tests aus, wenn die Änderung gemeinsames Verhalten beeinflussen kann. - Reproduzieren Sie bei der Behebung von Fehlern in der kontinuierlichen Integration jede erforderliche Konfiguration in der dokumentierten Reihenfolge. - Beziehen Sie Konfigurationsmatrix-, vektorisierte Ausführungs-, Sanitizer- und Zusicherungskompilierungen ein, wenn die betroffene Grenze dies erfordert. - Ersetzen Sie ein fehlgeschlagenes maßgebliches Prüftor nicht durch eine schnellere lokale Konfiguration, solange nicht belegt ist, dass der Unterschied unerheblich ist. ## Vor dem Beheben die Abfrage vom SQL-Parsing bis zum Ergebnis verfolgen Verfolgen Sie das Verhalten über den gesamten Lebenszyklus einer Abfrage, statt nur das erste Modul zu korrigieren, in dem ein Symptom auftritt. ### Verarbeitungsstufen 1. Zerlegen Sie SQL-Text in Syntaxbäume für Anweisungen, Ausdrücke und Tabellenverweise. 2. Binden Sie beim Erstellen eines logischen Plans Namen und Typen an den Katalog. 3. Optimieren Sie den logischen Plan mit semantikerhaltenden Regeln und kostenbasierten Entscheidungen. 4. Wandeln Sie logische Operatoren in physische Operatoren um. 5. Führen Sie physische Operatoren über vektorisierte, parallele Verarbeitungsketten aus. 6. Geben Sie Ergebnisse über die Verbindung und den Clientkontext zurück. ### Zuständigkeit der Komponenten - Halten Sie Grammatik und Parsertransformationen synchron; jede Grammatikregel benötigt die entsprechende Transformation. - Der Planer ist für Bindung, Typauflösung, Unterabfragen und logische Operatoren zuständig. - Der Optimierer transformiert Pläne, ohne die beobachtbare Semantik zu ändern. - Die Ausführungsschicht ist für physische Planung, Operatoren und Ausdrucksauswertung zuständig. - Belassen Sie dauerhafte Speicherung, Pufferung, Komprimierung, Kontrollpunkte und Write-Ahead-Protokollierung in der Speicherschicht. - Behandeln Sie den Katalog als einzige maßgebliche Quelle für Schemata, Tabellen, Funktionen und Typen. - Halten Sie Transaktionen, Rücknahmestatus und Mehrversions-Nebenläufigkeitskontrolle von Aufgabenplanung und parallelen Verarbeitungsketten getrennt. ## Daten spaltenweise in Batches verarbeiten und Besitzregeln einhalten Eine analytische Engine hängt von klaren Unterscheidungen zwischen analysierter Syntax, gebundenen Ausdrücken, Spaltenidentität, physischen Vektoren und Besitzverhältnissen ab. ### Datenfluss - Verarbeiten Sie Daten in spaltenorientierten Stapeln statt zeilenweise. - Stellen Sie jede Stapelspalte mit der Vektorabstraktion der Engine dar. - Führen Sie bei Planung und Ausführung ein stabiles Paar aus Tabellen- und Spaltenindex mit. - Halten Sie analysierte Ausdrücke ungebunden und von typisierten, gebundenen Ausdrücken getrennt. - Werten Sie gebundene Ausdrücke mit dem vektorisierten Ausdrucksausführer aus. ### Besitzverhältnisse und Typen - Verwenden Sie standardmäßig exklusiven intelligenten Besitz. - Verwenden Sie geteilten Besitz nur, wenn mehrere Lebensdauern ihn tatsächlich erfordern. - Unterscheiden Sie nullfähige, nicht besitzende Referenzen von garantiert nicht leeren Referenzen. - Verwenden Sie niemals rohe besitzende Zeiger. - Leiten Sie Typheraufstufungen und Typumwandlungen durch einen einzigen maßgeblichen Regelsatz. - Fügen Sie benutzerdefinierte Typen über den Erweiterungsmechanismus hinzu, statt das Typsystem zu umgehen. - Verwenden Sie Besuchermuster für Baumdurchläufe, Fabriken für die Deserialisierung und typisierte Unterklassen für Operator-, Eintrags- und Ausdruckshierarchien. ## Erweiterungen und erzeugte Dateien in ihrer Quelle ändern Behandeln Sie im Quellbaum enthaltene Erweiterungen, extern gepflegte Erweiterungen, erzeugten Code und Veröffentlichungsartefakte als verschiedene Besitzklassen. ### Erweiterungsgrenzen - Bearbeiten Sie Erweiterungen im Quellbaum direkt in ihrem angegebenen Quellverzeichnis. - Halten Sie extern gepflegte Erweiterungen in getrennten Repositorys und wenden Sie repositoryeigene Änderungen über den vorgesehenen Korrekturmechanismus an. - Unterstützen Sie sowohl die Kompilierung des vollständigen Erweiterungssatzes als auch einer ausdrücklich angegebenen Teilmenge. - Testen Sie Erweiterungsänderungen gegen dieselben Kernschnittstellen und Typregeln, die integrierte Funktionen verwenden. ### Erzeugte Artefakte - Ermitteln Sie die Quelldateien, die API-Anbindungen, Registrierungen, Einstellungen, Serialisierungscode, Speichermetadaten, Messwerte und Aufzählungshilfen erzeugen. - Bearbeiten Sie die Quelle eines erzeugten Artefakts, niemals nur dessen erzeugte Ausgabe. - Führen Sie nach Quelltextänderungen das genehmigte Generierungsziel aus. - Prüfen Sie erzeugte Unterschiede auf sachfremde Änderungen und formatieren Sie sie mit dem Standardformatierer. ## Den C++-Stil einhalten und Kommentare kurz halten Einheitlichkeit in systemnahem Code verringert Unklarheiten bei Besitzverhältnissen, Indizes, öffentlichen Schnittstellen und Kontrollfluss. ### Codestil - Verwenden Sie die Einrückungs- und Ausrichtungsregeln des Repositorys und erzwingen Sie dessen Zeilenbreitengrenze mit dem Formatierungswerkzeug. - Ziehen Sie Ganzzahltypen fester Breite plattformabhängigen Ganzzahlbreiten vor. - Verwenden Sie für Versätze, Indizes und Anzahlen den vom Projekt vorgesehenen Indextyp. - Übergeben Sie nicht triviale, schreibgeschützte Objekte als konstante Referenz. - Bevorzugen Sie bereichsbasierte Schleifen, wenn sie den Durchlauf eindeutig ausdrücken. - Verwenden Sie bei Bedingungen und Schleifen immer geschweifte Klammern. - Verwenden Sie niemals `const_cast`. - Befolgen Sie die etablierten Benennungskonventionen für Dateien, Typen, Variablen und Funktionen. ### Kommentare - Halten Sie Kommentare kurz und überlassen Sie die gewöhnliche Erklärung verständlichem Code. - Kommentieren Sie dauerhafte Absichten, Einschränkungen oder nicht offensichtliche Invarianten. - Hinterlassen Sie keinen auf ein bestimmtes Problem bezogenen Reparaturverlauf im Code. - Dokumentieren Sie Änderungsgeschichten wie die Behebung eines Versatzfehlers um eins in der Änderungsbeschreibung oder Commitnachricht. - Verwenden Sie längere Kommentare nur, wenn die Invariante nicht durch Codestruktur und Benennung verständlich gemacht werden kann. ## Je nach Fehlerart Ausnahmen oder Assertions wählen und SQL-Logiktests schreiben Wählen Sie den Fehlerkanal danach, ob eine Abfrage beendet werden muss, sich erholen kann oder auf einen internen Programmierfehler gestoßen ist. ### Fehlerrichtlinie - Verwenden Sie Ausnahmen für abfragebeendende Fehler wie Analysefehler, fehlende Objekte oder erschöpften Speicher. - Verwenden Sie Rückgabewerte für Bedingungen, von denen sich dieselbe Abfrage erholen kann. - Verwenden Sie Debugzusicherungen für Programmierfehler, die durch Benutzereingaben niemals ausgelöst werden dürfen. - Formulieren Sie Zusicherungen so genau, dass sie die verletzte Invariante erkennen lassen. - Wandeln Sie erwartete ungültige Eingaben nicht in einen internen Zusicherungsfehler um. ### SQL-Logiktests - Bevorzugen Sie für das Abfrageverhalten deklarative SQL-Logiktests gegenüber C++-Tests. - Kennzeichnen Sie Anweisungen, die erfolgreich sein müssen, getrennt von Anweisungen, die fehlschlagen müssen. - Deklarieren Sie für Abfragen die erwarteten Ergebnisspaltentypen. - Trennen Sie den Abfragetext mit dem kanonischen Trennzeichen des Rahmenwerks von den erwarteten Zeilen. - Verwenden Sie reguläre Ausdruckserwartungen für Fehlertext nur, wenn der genaue Wortlaut absichtlich instabil ist. - Deklarieren Sie erforderliche Umgebungsvariablen ausdrücklich. - Kennzeichnen Sie langsame Tests mit der Langsamtest-Markierung des Rahmenwerks, damit Standardläufe praktikabel bleiben. - Decken Sie numerische, Zeichenketten- und verschachtelte Typen sowie ungültige und unerwartete Verwendungen ab, statt nur den Erfolgsfall zu prüfen. - Verlangen Sie vor der Einreichung, dass die vollständige maßgebliche Testsammlung erfolgreich ist. ## Über Tests die zu ändernde Stelle finden und alle nötigen Prüfungen abschließen Lokalisieren Sie eine Funktion vor dem Bearbeiten anhand von Tests und Architekturzuständigkeiten und prüfen Sie anschließend jede von der Änderung betroffene abgeleitete Oberfläche. ### Untersuchungsablauf 1. Suchen Sie vorhandene Tests, um die unterstützte Syntax und das erwartete Verhalten zu verstehen. 2. Verfolgen Sie die Funktion vom Parser über Binder, Optimierer und physische Planung bis zur Ausführung. 3. Ermitteln Sie die entsprechenden Anweisungs-, Operator-, Ausdrucks-, Katalog- oder Funktionstypen. 4. Prüfen Sie, wo die Funktion registriert ist und wo sich ihre öffentliche Deklaration befindet. 5. Durchsuchen Sie Implementierungsdateien und öffentliche Header mit dem standardmäßigen Codesuchwerkzeug des Repositorys. 6. Ermitteln Sie erzeugte Dateien und Erweiterungsoberflächen, die von der geänderten Quelle abhängen. ### Abschlussprüfungen - Fügen Sie vor umfassenden Tests gezielte Regressionstests hinzu oder aktualisieren Sie sie. - Führen Sie Formatierung und Quellgenerierung aus. - Führen Sie zuerst den gezielten Test und danach die erforderlichen Komponenten-, Langsam-, Sanitizer-, Zusicherungs-, Konfigurations- und Vektortestsammlungen aus. - Kompilieren Sie die betroffene ausführbare Datei und die betroffenen Erweiterungen. - Prüfen Sie erzeugte Unterschiede und Dokumentationszuständigkeiten. - Melden Sie den Abschluss erst, wenn jedes erforderliche Prüftor ein tatsächliches Ergebnis hat.