Syntax, Datentypen, Funktionen und Fehlernummern je Abfragesprache — jeder Abschnitt mit einem Beispiel aus dem Beispielkatalog und, wo die Sprache einen eigenen Sprachmeilenstein der Roadmap hat, dem Stand jedes einzelnen Punktes daraus.
Über Port 8086 (1.x oder 2.x) und 8181 (3.x), beide voreingestellt aus,
spricht KuonenSQL die HTTP-Schnittstelle von InfluxDB: Line-Protokoll zum Schreiben, InfluxQL, Flux (2.x: die Abfragefunktionen samt window, quantile, join, union, to() und den Paketen schema und array) und SQL (3.x), dazu Flight SQL.
Eine Datenbank von InfluxDB ist eine Datenbank von KuonenSQL, eine Aufbewahrungsrichtlinie ein Schema, eine Messung eine Tabelle; jede Shard-Gruppe ist eine
Partition auf ihrer eigenen Dateigruppe. Angemeldet wird mit einer Anmeldung von KuonenSQL, die Rechte (READ, WRITE) sind T-SQL-Rechte.
Die Beispiele schreiben wie das Werkzeug influx: USE wählt die Datenbank, INSERT schreibt eine Zeile im Line-Protokoll.
| Punkt | Beschreibung | Stand |
|---|---|---|
IX37.1 Referenzorakel InfluxDB 1, 2 und 3 |
Drei Container (`influxdb:1.11`, `influxdb:2.7`, `influxdb:3-core`) nur auf 127.0.0.1, gestartet und entfernt über `dist\orakel-ref.ps1 -Dialekt influx1`, `influx2`, `influx3` (Download erst bei Bedarf, nach den Messungen wieder weg). Messwerkzeug `tools/influx` (Python, nur Standardbibliothek: HTTP-Aufrufe, Antwort roh als Fixture); Beispielpunkte mit allen Feldtypen, Sonderzeichen in Tags und Messungsnamen und allen Genauigkeiten. **Erledigt 23.10.2026:** `orakel-ref.ps1 -Dialekt influx1|influx2|influx3` (Wegwerf-Container mit Zufallszugang, `-Behalten`/`-Entfernen`), Messwerkzeug `tools/influx/influx-orakel.py`; erste Messreihe `Influx/Fixtures/grundlagen-v1..v3` (40/48/50 Anfragen) mit HERKUNFT.md. | ✅ |
IX37.2 Zugangsmodul InfluxDB |
Zugang `Influx` als Modul über die gemeinsamen Nahtstellen (`docs/neuer-dialekt.md`, `DialektArchitekturTests`): eigener HTTP-Hörer (Vorgabe aus; `KUONENSQL_INFLUX_PORT`, üblich 8086 für 1.x/2.x, `KUONENSQL_INFLUX3_PORT`, üblich 8181 für 3.x), TLS wie die übrigen Zugänge, `Content-Encoding: gzip`, Kopfzeilen `X-Influxdb-Version`/`X-Influxdb-Build` je Fassung; `/ping` (204, auch `verbose`), `/health`, `/metrics` (Prometheus-Text, Grundwerte). Anmeldung je Fassung: 1.x `u`/`p` in der Adresse und Basic, 2.x/3.x `Authorization: Token …` bzw. `Bearer`; Benutzer und Token in der gemeinsamen Benutzerverwaltung (M26). **Erledigt 23.10.2026:** Modul `Influx/` (Einstellungen, Dienst, HTTP-Weg) mit Hörern `influx` (1.x/2.x, `KUONENSQL_INFLUX_FASSUNG`) und `influx3` in der Zugangsverwaltung (`sp_kuonensql_zugang`, Lizenzmerkmal `sql:protocol.influx`); `/ping`, `/health`, `/ready`, `/metrics`, `/debug/vars`, CORS, gzip (1.x) und die Anmeldung je Fassung wie gemessen (`zugang-v1..v3`). HTTP-Leser und Anmeldeprüfung samt Sperre aus GraphQL nach `Protocol/` verschoben (ein Weg für alle HTTP-Zugänge). Eigene Token → IX37.10/IX37.12, Rest → IX37.2a. | ✅ |
IX37.2a Rest aus IX37.2 |
`GET /api/v2` (Wegeliste wie 2.7), `/debug/pprof` (2.x) und die Prometheus-Werte unter den Namen des Orakels, soweit KuonenSQL sie hat (`/metrics` liefert bisher eigene Grundwerte `kuonensql_influx_*`); Bearer-JWT mit gemeinsamem Geheimnis wie 1.x (`shared-secret`); die Oberfläche von 2.x unter `/` gibt es nicht (404 statt HTML, gewollt). Erledigt 2026-10-24, gemessen an 1.11, 2.7 und 3-core. - `GET /api/v2` (auch `/api/v2/`, ohne Anmeldung) liefert die Wegeliste von 2.7 wörtlich (Fixture wege-v2). - `/metrics` hat die Familien unter den Namen des Orakels, soweit KuonenSQL Werte hat: - 1.x/2.x: go_goroutines, go_info, go_memstats_*_bytes und go_threads, gerechnet aus der Laufzeit von .NET, dazu process_*. - 2.x zusätzlich: influxdb_*_total aus dem Katalog, influxdb_info, influxdb_uptime_seconds{id} und http_api_requests_total{handler,method,path,response_code,status,user_agent}. - 3.x: http_requests_total{method,method_path,path,status} und process_start_time_seconds mit den Angaben von 3.x. - Bearer-JWT mit gemeinsamem Geheimnis an 1.x (`KUONENSQL_INFLUX_SHARED_SECRET`): HS256/384/512 mit den Meldungen und der Reihenfolge des Orakels. Ohne Geheimnis bleibt es bei `bearer auth disabled`. Bewusst nicht gebaut: `/debug/pprof`, das sind Laufzeitprofile von Go. Auch die Oberfläche von 2.x unter `/` bleibt 404. Tests InfluxZugangTests (Metriken je Fassung, Wegeliste, JWT), Lauf Influx, Flux, Beispielkatalog 171/171. Sabotage ok (Unterschrift nicht geprüft → rot). | ✅ |
IX37.2b Befund: TLS am Influx-Port nur auf Verlangen |
Bei der Probe mit Grafana (23.10.2026): der Server erzeugt für TDS immer ein selbstsigniertes Zertifikat, der Influx-Zugang übernahm es und sprach HTTPS — Grafana, Telegraf und die Clients sprechen ohne Angabe `http://` (InfluxDB: `https-enabled = false`), die Verbindung brach ab. TLS nur mit `KUONENSQL_INFLUX_TLS=an`. **Erledigt 23.10.2026:** `InfluxEinstellungen.AusUmgebung` nimmt das Zertifikat nur mit `KUONENSQL_INFLUX_TLS=an|1|true`. Probe mit `grafana/grafana:11.6.0` gegen einen Server aus dem Zweig (Fassung 1): „Save & test“ OK, Zeitreihe je Host, alle Abfragen des Abfrage-Editors beantwortet. Test `TLS_nur_auf_Verlangen_wie_InfluxDB`. | ✅ |
IX37.3 Datenmodell und Abbildung |
Messung, Tags, Felder und Zeit auf Tabellen wie oben; Serienschlüssel (Messung und sortierte Tags) als Index; ein Feld ohne Wert in einem Punkt bleibt NULL; Typkonflikt eines Felds mit der Meldung des Orakels (1.x/2.x `field type conflict`, 3.x eigene) statt stiller Umwandlung; gleiche Serie und Zeit führt die Felder zusammen (am Orakel messen, ob ersetzt oder ergänzt); neue Spalten ohne Sperre der ganzen Tabelle; Katalogeintrag, damit die Tabellen in `sys.tables`, `information_schema` und im Studio als Zeitreihen erkennbar sind; Lesen und Schreiben derselben Zeilen über T-SQL, KSQL und PostgreSQL (M26). **Erledigt 23.10.2026:** `Influx/InfluxAblage.cs`: jede Datenbank von KuonenSQL ist eine Influx-Datenbank, Richtlinie = Schema (`autogen`), Messung = Tabelle mit `_serie` (Serienschlüssel) und `time` (bigint ns) als Primärschlüssel, berechneter `_zeit datetime2(7)`, Tags `nvarchar(max) BIN2`, Felder typisiert (`u` → `decimal(20,0)`); Katalog `influx.richtlinien/messungen/felder` für Gross-/Kleinschreibung und lange Namen; Zusammenführen gleicher Serie und Zeit per `MERGE` in einer Transaktion je Anfrage; Typkonflikte und `time` je Fassung wie gemessen; Lesen/Ändern über T-SQL, KSQL, PostgreSQL, `JOIN` mit Stammdaten. Engine-Befunde dabei → IX37.3a, IX37.3b; Reste → IX37.3c. | ✅ |
IX37.3a Befund: DATEADD mit Nanosekunden und in berechneten Spalten |
Am Orakel (SQL Server 2025, 23.10.2026): `DATEADD(NANOSECOND, n, …)` rundet auf 100 ns, die Hälfte weg von der Null (KuonenSQL schnitt ab); Einheiten, die nicht zum Typ passen (date ohne Uhrzeitteile, time ohne Datumsteile, datetime/smalldatetime/Text ohne Mikro- und Nanosekunden), sind 9810 `The datepart … is not supported by date function dateadd for data type …` (KuonenSQL rechnete); in einer berechneten Spalte galt der Datumsteil von `DATEADD`/`DATEDIFF` … als Spaltenname (207). Gefunden beim Bau der Spalte `_zeit` (IX37.3). **Erledigt 23.10.2026:** Rundung `NanosekundenAlsTicks` (auch für Weitzeit), Prüfung Einheit/Typ mit 9810 und dem Wortlaut des Orakels, `Modulverweise` übergeht den Datumsteil der Funktionen mit Datumsteil (`Ausdrucksplan.MitDatumsteil`). `DateaddEinheitenTests` (23). | ✅ |
IX37.3b Befund: ALTER TABLE ADD mit COLLATE |
Am Orakel (SQL Server 2025, 23.10.2026): `ALTER TABLE t ADD s nvarchar(max) COLLATE Latin1_General_BIN2` legt die Spalte mit dieser Sortierung an (`sys.columns.collation_name`, Vergleich und `ORDER BY` binär); KuonenSQL verwarf die Angabe still (bei `CREATE TABLE` galt sie schon). Gefunden beim Bau der Tag-Spalten (IX37.3). **Erledigt 23.10.2026:** der Spaltenleser von `ALTER TABLE … ADD` liest `COLLATE` (ausser im Dialekt MySQL, der es schon über `CHARACTER SET`/`COLLATE` kennt) und gibt sie der Textspalte. `AlterAddSortierungTests`. | ✅ |
IX37.3c Rest aus IX37.3 |
Schreiben derselben Datenbank läuft hinter einem Riegel je Datenbank, und der Katalog wird je Anfrage gelesen — für die Schreibrate (M34) Katalog im Speicher mit Abgleich und feinere Sperre (neue Spalten ohne die ganze Datenbank zu halten); ±Unendlich (3.x nimmt `1e400` an) wird bisher NULL statt des Werts; ein Tag und ein Feld gleichen Namens in 1.x/2.x liegen in zwei Spalten (Abfrage wie das Orakel mit IX37.6); Markierung der Tabellen als Zeitreihen im Studio (mit IX37.17). Erledigt 2026-10-24, gemessen an 1.11 (gleichname-v1) und 3-core (unendlich-v3). Tag und Feld gleichen Namens laufen wie das Orakel und sind jetzt belegt (InfluxqlV1Tests.Tag_und_Feld_gleichen_Namens_…, alle 12 Fälle): - `x` ist das Feld, `x::tag` gibt nichts; - `*` zeigt `x` und `x_1`; - `WHERE x = 'a'` gibt nichts, `GROUP BY x` gruppiert nach dem Tag. Das Schreiben von ±Unendlich in 3.x ist belegt: `1e400` geht, `inf`/`NaN` als Wort nicht (InfluxApiV3Tests.Unendlich_schreiben_…). Reste als eigene Zeilen: - IX37.3d: ±Unendlich in float im Kern; der Wert landet bisher als NULL. - IX37.3e: Schreibrate mit Katalog im Speicher und feinerer Sperre, mit M34. - Die Markierung als Zeitreihe im Studio steht bei IX37.17c. | ✅ |
IX37.3d Kern: ±Unendlich und NaN in float wie PostgreSQL |
Rest aus IX37.3c (gemessen unendlich-v3). 3.x schreibt `1e400` und `-1e400` als ±Unendlich. Gelesen zeigt JSON `null`, CSV `inf`/`-inf`; sum, max und min ergeben `null`. In KuonenSQL wird der Wert NULL. `float` im Kern kennt kein ±Unendlich, wie bei SQL Server; PostgreSQL kennt `Infinity`, MySQL nicht. Das Protokoll hält Stapel als Text, darum reicht kein Kniff im Influx-Teil. Zu entscheiden (Marc): soll `float` im Kern ±Unendlich und NaN halten können, wie PostgreSQL? Dann gehören dazu: - das Lesen als Text (`'Infinity'`) über PostgreSQL und KSQL; - die Ausgabe über TDS (SQL Server lehnt den Wert ab) und MariaDB; - Vergleich und Sortierung wie PostgreSQL. Erledigt 2026-10-24 (Entscheid Marc: ja, wie PostgreSQL), gemessen an postgres:17. `float` hält ±Unendlich und NaN. PostgreSQL: - liest `Infinity`, `inf` und `NaN` mit Vorzeichen und in jeder Schreibung; - gibt `Infinity`, `-Infinity` und `NaN` aus; - `'1e400'` meldet „is out of range for type double precision“. Für alle Dialekte gilt: - NaN ist gleich NaN und grösser als alles, die Reihenfolge ist −∞ < Zahlen < +∞ < NaN; - ∞ − ∞ ergibt NaN, ein Überlauf aus endlichen Werten bleibt ein Fehler; - sum, avg und max mit NaN ergeben NaN; `Infinity::int` meldet „integer out of range“. Über die Zugänge: - TDS liefert die IEEE-Zahl (SqlClient liest ∞ und NaN), als Text `Infinity`; - MariaDB zeigt `inf`, `-inf` und `nan` wie C; - T-SQL und KSQL lesen Text mit Sonderwert nicht (8114 wie SQL Server). InfluxDB 3 schreibt `1e400` als Wert: nach dem MERGE ein Stapel im Dialekt von PostgreSQL in derselben Transaktion; das Protokoll spielt ihn in diesem Dialekt ab. Tests: PgUnendlichTests (alle Fälle des Orakels), FloatSonderwerteKreuzTests (TDS, MariaDB, PostgreSQL, KSQL), InfluxApiV3Tests.Unendlich_schreiben_… (ohne U6, U7 wie W20). Lauf Pg, Maria, Float, Zahl, Influx, Ksql, Vergleich 6319/6319. Sabotage ok (NaN-Ordnung aus → 2 rot; Influx-Nachtrag aus → rot). | ✅ |
IX37.3e Schreibrate: Katalog im Speicher, feinere Sperre (mit M34) |
Rest aus IX37.3c, mit M34 (Leistung erst nach dem Bau). Das Schreiben derselben Datenbank läuft hinter einem Riegel je Datenbank, und der Katalog (Messungen, Spalten) wird je Anfrage gelesen. Für die Schreibrate gehört der Katalog in den Speicher, mit Abgleich bei Änderungen über die SQL-Zugänge, und eine feinere Sperre (neue Spalten ohne die ganze Datenbank zu halten). Messen gegen Telegraf und die Schreibrate von 1.x/2.x am Orakel. **Erledigt 25.10.2026:** Die Bremse war das MERGE (es las je Rumpf die ganze Messung); es sucht jetzt bei einem ON aus Gleichheiten über das Schlüsselverzeichnis einer Zahlenspalte (time). Dazu der Katalog im Speicher mit Abgleich über den Änderungsstand der Katalogtabellen (auch bei Änderungen über SQL) und eine Lese-/Schreibsperre je Datenbank mit Sperre je Messung beim Einfügen. Gemessen (10 Punkte je Rumpf): ein Schreiber 431 → 3148 Punkte/s, gleichbleibend über die Grösse; vier Schreiber 1377 → 3682 Punkte/s. Vergleich mit Telegraf/1.x/2.x am Orakel im Dauerlauf (IX37.17c). | ✅ |
IX37.4 Line-Protocol-Leser |
Vollständige Syntax: Messung, Tag-Satz, Feld-Satz, Zeitstempel; Maskierung von Komma, Leerzeichen, Gleichheitszeichen, Anführungszeichen und Rückstrich je Stelle; Feldtypen `i`, `u`, Gleitkomma (auch `1e3`), `"Text"`, Wahrheitswerte in allen Schreibweisen; Genauigkeit `ns`/`us`/`ms`/`s` (2.x/3.x auch die langen Namen), fehlender Zeitstempel = Serverzeit; Kommentarzeilen, leere Zeilen, CRLF. Einfügen stapelweise (eine Transaktion je Anfrage), Teilfehler wie das Orakel (1.x 400 `partial write` mit Zeilennummer, 3.x `accept_partial`). Fuzzing des Lesers wie PR27.7. **Erledigt 23.10.2026 (Leser):** `Influx/LineProtokoll.cs` liest je Fassung wie gemessen (`lp-v1..v3`: 48 Fehler- und 20 Grenzfälle, `lp2-v1..v3`: Fluchtzeichen in Namen, mehrere Fehler je Anfrage, Kommentare, CR, Tabulatoren): 1.x/2.x mit den Regeln und Meldungen des Go-Lesers, 3.x mit denen des eigenen Lesers samt seiner Zeilennummern; Genauigkeit als Nanosekunden je Einheit, 3.x automatisch. Fuzzing 3 × 20 000 Rümpfe. Einfügen je Anfrage und Teilfehler mit dem Schreibweg → IX37.5. | ✅ |
IX37.5 1.x: Schreib-API |
`POST /write?db=&rp=&precision=&consistency=` mit Line Protocol im Rumpf, 204 bei Erfolg, Fehler als JSON `{"error": …}` mit dem Statuscode des Orakels (400, 401, 404 `database not found`, 413, 500); unbekannte Aufbewahrungsrichtlinie; Grösse des Rumpfs begrenzt (`max-body-size`). **Erledigt 23.10.2026:** `Influx/InfluxSchreiben.cs`: `POST /write` mit `db`, `rp`, `precision` (`n`/`ns`, `u`, `ms`, `s`, `m`, `h`), `consistency` (angenommen; ein Knoten), gzip mit Grenze auch entpackt (Schutz vor gepackter Bombe), 204/400/404/405/413/500 und `X-Influxdb-Error` wie gemessen; Teilschreiben wie 1.x (Lesefehler verwerfen ihre Zeilen, `partial write: … dropped=N`, Konflikt im Rumpf `field type conflict`), eine Transaktion je Anfrage. Alle 24 Schreibfälle von `grundlagen-v1` und die 88 Fälle von `lp-v1`/`lp2-v1` über HTTP gleich wie 1.11. Rechte `WRITE` → IX37.8. | ✅ |
IX37.6 1.x: InfluxQL-Abfragen |
`GET`/`POST /query?db=&q=&epoch=&chunked=&chunk_size=&pretty=¶ms=` mit mehreren Anweisungen je Aufruf, Antwort `{"results":[{"statement_id",…,"series":[{"name","tags","columns","values"}]}]}` exakt wie das Orakel (Reihenfolge, Zeit als RFC3339 oder `epoch`, Ganzzahlen ohne Nachkommastellen), CSV mit `Accept: application/csv`. Sprache: `SELECT` mit Feldern, Tags, `*`, `::field`/`::tag`, Arithmetik; `FROM` mit mehreren Messungen, regulären Ausdrücken und Unterabfrage; `WHERE` mit Zeitbereichen (`now()`, Dauern wie `1h`, `-7d`, RFC3339-Texte), Tag-Vergleichen, `=~`/`!~`, `AND`/`OR`; `GROUP BY` Tags, `*` und `time(intervall, versatz)`; `fill(null)`, `fill(none)`, `fill(previous)`, `fill(linear)`, `fill(<Zahl>)`; `ORDER BY time DESC`; `LIMIT`, `OFFSET`, `SLIMIT`, `SOFFSET`; `tz('Europe/Zurich')`; gebundene Werte über `params`. **Erledigt 23.10.2026:** InfluxQL von 1.x im Eigenbau: Zerleger und Parser nach dem Verhalten des Go-Parsers (Meldungen mit Zeile/Zeichen, gebundene Werte), Ausführer (Quellen samt Regex, `db.rp.m`, `db..m`, Unterabfragen; Zeitbereich aus `WHERE` an die Engine; Tag-/Feldbedingungen, Serien, `GROUP BY` Tags/`*`/`time(i,o)`, `fill` alle fünf, `ORDER BY time DESC`, `LIMIT`/`OFFSET`/`SLIMIT`/`SOFFSET`, `tz()`), Ausgabe wie 1.x (JSON mit Go-Zahlen und RFC3339Nano, `epoch`, `pretty`, `chunked` mit `partial`, CSV), `/query` per GET/POST-Formular. Alle 91 verglichenen Blöcke von `influxql-v1` gleich wie 1.11 (auch die Reihenfolge gleicher Zeiten aus dem Heap von Go). Verwaltungsanweisungen → IX37.8, weitere Funktionen → IX37.7, `/query` an 2.x/3.x → IX37.10/IX37.12. | ✅ |
IX37.7 1.x: InfluxQL-Funktionen |
Aggregate (`COUNT`, `DISTINCT`, `INTEGRAL`, `MEAN`, `MEDIAN`, `MODE`, `SPREAD`, `STDDEV`, `SUM`), Selektoren mit der Zeit des gewählten Punkts (`BOTTOM`, `FIRST`, `LAST`, `MAX`, `MIN`, `PERCENTILE`, `SAMPLE`, `TOP`), Umformungen (`ABS`, Winkelfunktionen, `CEIL`, `FLOOR`, `ROUND`, `EXP`, `LN`, `LOG`, `POW`, `SQRT`, `CUMULATIVE_SUM`, `DERIVATIVE`, `NON_NEGATIVE_DERIVATIVE`, `DIFFERENCE`, `NON_NEGATIVE_DIFFERENCE`, `ELAPSED`, `MOVING_AVERAGE`), technische Analyse (`CHANDE_MOMENTUM_OSCILLATOR`, `EXPONENTIAL_MOVING_AVERAGE`, `DOUBLE_EXPONENTIAL_MOVING_AVERAGE`, `KAUFMANS_EFFICIENCY_RATIO`, `KAUFMANS_ADAPTIVE_MOVING_AVERAGE`, `TRIPLE_EXPONENTIAL_MOVING_AVERAGE`, `TRIPLE_EXPONENTIAL_DERIVATIVE`, `RELATIVE_STRENGTH_INDEX`), Vorhersage `HOLT_WINTERS`/`HOLT_WINTERS_WITH_FIT`; Ergebnisse bis aufs Bit wie das Orakel (Gleitkomma wie PR27.24d). **Erledigt 23.10.2026:** alle Funktionen wie 1.11 nach Quelltext nachgebaut (Mischreihenfolge, dreistufige Reduktion, Zwei-Punkte-Grenze bei first/last, pdqsort, Go-Mathematik bitgleich, Prüfung wie compile.go); funktionen-v1 160/160, funktionen2-v1 104/104, selektoren-v1 96/96. Rest IX37.7a. | ✅ |
IX37.7a 1.x: Funktionen über mehrere Shards |
IX37.7 rechnet wie ein einziger Shard (Teilergebnisse je Serie → Shard → Abfrage). Liegen Daten in mehreren Shard-Gruppen (z. B. über mehrere Wochen bei autogen), mischt 1.x je Shard und dann über die Shards: am Orakel mit Daten über drei Wochen messen (mean/sum in Gleitkomma, first/last mit Grenze 2 je Shard, percentile-Reihenfolge) und nachbauen. Erledigt 2026-10-23 (gemessen shards2-v1, Daten über drei Wochen-Shards, Werte mit Auslöschung): count/sum/mean/min/max/first/last rechnen je Serie und Shard vor; die Shards laufen im Heap von Go zusammen (gleiche Fenster in der Reihenfolge 1, n, n-1 …), sodass Gleitkommasummen genau wie 1.x ausfallen (sum 4 statt 3.9). Rohpunkte mischt jeder Shard für sich, die Shards hängen nach ihrer Zeit aneinander (gleiche Zeiten nach Serie). 30/31 Blöcke gleich, auch integral, percentile, mode, top/bottom, GROUP BY time(1w). Rest: Unterabfragen (F28) → IX37.7b. | ✅ |
IX37.7b 1.x: Unterabfragen über mehrere Shards |
Rest aus IX37.7a (shards2-v1 F28): `SELECT sum(x) FROM (SELECT v AS x FROM m)` über drei Shards ergibt am Orakel 2.5, KuonenSQL 3.0999999999999996. Nachgerechnet: die Unterabfrage gibt ihre Punkte ungeordnet weiter — die Shards im MergeIterator (Heap: 1, n, n-1 …), darin Serie um Serie (a ganz, dann b), erst dann summiert die äussere Abfrage. KuonenSQL ordnet die Punkte einer Unterabfrage nach Zeit (AlsMessung, IqlGruppe). Nachbauen samt der Frage, wann 1.x die innere Abfrage geordnet liest (äussere Rohabfrage, GROUP BY time). Erledigt 2026-10-24, gemessen an influxdb:1.11 (Fixture shards3-v1, U1–U15). Liest eine Aggregatabfrage eine innere Rohabfrage, kommen deren Punkte ungeordnet: die Shards in der Folge des Heaps von Go (1, n, n-1 … 2), darin Serie um Serie, jede nach Zeit. Das gilt auch mit GROUP BY time über alle Shards, mit Rechnung, Bedingung, innerem GROUP BY s und verschachtelt. F28 und U1 ergeben 2.5, U2 0.25. Eine äussere Rohabfrage und ein inneres Aggregat bleiben nach Zeit geordnet (U4, U5, U15; U12 ergibt 3.0999999999999996). Jede Unterabfrage liest die äussere Abfrage als einen Strom, ohne Teilergebnisse je Serie. first/last über eine Unterabfrage reduzieren ohne den Sonderweg der Engine (Grenze 1): früheste bzw. späteste Zeit, bei Gleichstand der grössere Wert (U6 ergibt 0.3 und 0.7). Tests: InfluxqlFunktionenV1Tests mit shards2-v1 ganz (F28 jetzt dabei) und shards3-v1 ganz; Lauf Influx, Flux, Beispielkatalog 168/168. Sabotage ok (ungeordnetes Lesen aus → 2 rot; Strom aus → 2 rot). | ✅ |
IX37.8 1.x: Verwaltung und Schemaerkundung |
`SHOW DATABASES`, `SHOW MEASUREMENTS` (auch `WITH MEASUREMENT =~`), `SHOW TAG KEYS`, `SHOW TAG VALUES WITH KEY`, `SHOW FIELD KEYS`, `SHOW SERIES`, `SHOW RETENTION POLICIES`, `SHOW USERS`, `SHOW GRANTS`, `SHOW CONTINUOUS QUERIES`, `SHOW QUERIES`, `SHOW STATS`/`SHOW DIAGNOSTICS` (Grundwerte), Kardinalitäten (`SHOW SERIES CARDINALITY` u. a., auch `EXACT`); `CREATE`/`DROP DATABASE`, `CREATE`/`ALTER`/`DROP RETENTION POLICY` (Dauer, `REPLICATION` und `SHARD DURATION` angenommen, `DEFAULT`), `DROP MEASUREMENT`, `DROP SERIES`, `DELETE FROM … WHERE time …`, `CREATE`/`DROP USER`, `SET PASSWORD`, `GRANT`/`REVOKE` (`READ`, `WRITE`, `ALL`) auf die gemeinsamen Rechte (M26), `KILL QUERY`. **Erledigt 23.10.2026:** alle genannten Anweisungen gelesen (eigener Parserteil mit den Meldungen von 1.x) und ausgeführt (`InfluxqlVerwaltung`): SHOW DATABASES/MEASUREMENTS (WITH MEASUREMENT, WHERE, LIMIT/OFFSET, ON)/TAG KEYS/TAG VALUES (WITH KEY =, !=, =~, !~, IN)/FIELD KEYS/SERIES/RETENTION POLICIES/USERS/GRANTS/CONTINUOUS QUERIES/QUERIES/STATS/DIAGNOSTICS/SHARDS/SUBSCRIPTIONS, alle Kardinalitäten; CREATE/DROP DATABASE (auch WITH … NAME), CREATE/ALTER/DROP RETENTION POLICY (Mindestdauer, Vorgaben der Shard-Dauer), DROP MEASUREMENT/SERIES, DELETE (Felder in WHERE abgewiesen), CREATE/DROP USER, SET PASSWORD, GRANT/REVOKE auf Anmeldungen, `sysadmin` und Datenbankrollen, KILL QUERY, DROP SHARD, EXPLAIN; Warnung bei ändernden Anweisungen per GET. 103 von 107 Blöcken von `verwaltung-v1` gleich wie 1.11 (die übrigen wechseln je Lauf oder weichen gewollt ab). Engine-Befunde → IX37.8a, IX37.8b; Rest → IX37.8c. | ✅ |
IX37.8a Befund: USER_ID eines unbekannten Namens |
Am Orakel (SQL Server 2025, 23.10.2026): `USER_ID(N'gibtsnicht')` ist NULL; KuonenSQL gab 1 (wie `dbo`) — `IF USER_ID(N'x') IS NULL CREATE USER …` legte darum nie an. Gefunden bei `GRANT … ON db TO user` (IX37.8). **Erledigt 23.10.2026:** `EvaluateUserId` gibt für einen unbekannten Namen NULL. `UserIdTests`. | ✅ |
IX37.8b Befund: Rollensicht und Typ von USER_ID |
Gefunden bei IX37.8: (1) `sys.database_role_members` zeigt nach `ALTER ROLE db_datareader ADD MEMBER u` die Mitgliedschaft nicht (nur `db_owner/dbo`), `IS_ROLEMEMBER` kennt sie; am Orakel mit eigener Anmeldung messen und angleichen. (2) `USER_ID(…)` ist am Orakel `smallint`, in KuonenSQL `int` (Ergebnistyp in Auswertung und Typableitung). Erledigt 2026-10-23 (am Orakel SQL Server 2025 mit Benutzern ohne Anmeldung): Die festen Datenbankrollen wirken jetzt in der Rechtefrage (`PermissionManager.Erlaubt`). db_datareader liest und db_datawriter schreibt jedes Objekt, wie ein GRANT der Datenbankebene, das ein DENY am Objekt sticht. db_denydatareader und db_denydatawriter verbieten, auch gegen ein GRANT. `sys.database_role_members` zeigt die Mitgliedschaften in festen Rollen (deren Kennung kommt aus `DatenbankprinzipalKennung`). `USER_ID` ist smallint. Test `FesteDatenbankrollenTests` (9). Befund dabei: `UPDATE … WHERE` verlangt am Orakel auch SELECT → IX37.8e. | ✅ |
IX37.8ba Befund: DATABASE_PRINCIPAL_ID wurde smallint |
Gefunden beim Langläufer DdlOracleTests (Release 2.8): seit IX37.8b liefert USER_ID smallint, DATABASE_PRINCIPAL_ID reichte das für die festen Namen (dbo, public …) durch; am Orakel bleibt es int. Erledigt 2026-10-25: Datenbankprinzipal wandelt das Ergebnis von USER_ID für die festen Namen nach int. Prüfung: DdlOracleTests (Langläufer, 1111 Stapel gegen SQL Server 2022) vorher 1 Abweichung (b, c smallint), jetzt grün. | ✅ |
IX37.8c Rest aus IX37.8 |
Ein Benutzer mit nur `WRITE` braucht Lesezugriff auf den Katalog `influx.*` (Schreibweg liest ihn) — Recht auf das Schema mitgeben oder den Katalog unter dem Zugang lesen; `SHOW SHARDS`/`SHARD GROUPS` (KuonenSQL hat keine Shards: bisher je Datenbank leer), `SHOW STATS`/`SHOW DIAGNOSTICS` mit den Modulen und Werten von 1.x, soweit KuonenSQL sie hat; `SHOW QUERIES` und `KILL QUERY` brechen eine laufende Abfrage bisher nur über das Abbruchzeichen ab (in die Auswertung durchreichen); Zeitbedingungen in `SHOW TAG VALUES`/`SHOW SERIES`. Erledigt 2026-10-23: eigene Rechteschicht `InfluxRechte` wie bei MariaDB/PostgreSQL (Vorgabe Marc: die Rechte von KuonenSQL, über jeden Zugang gleich). READ ist `GRANT SELECT` auf der Datenbank, WRITE ist `GRANT INSERT, UPDATE, DELETE`, ALL beides; SHOW GRANTS liest sie zurück. Vor der Ausführung prüft die Schicht jede Anweisung wie 1.x (READ, WRITE oder Verwalter; 403 mit dem Wortlaut von 1.x), den Schreibweg vor allem anderen. SHOW DATABASES zeigt nur lesbare Datenbanken. Schreiben und Löschen laufen nach der Prüfung wie ein Modul mit `EXECUTE AS OWNER`, sodass ein Schreiber ohne SELECT schreiben kann. Zeitbedingungen in SHOW TAG KEYS/TAG VALUES/SERIES wählen ganze Shard-Gruppen; SHOW MEASUREMENTS und SHOW SERIES CARDINALITY lehnen Zeit ab wie 1.x. Fixture rechte-v1, 57/57 gleich. SHOW SHARDS → IX37.9a; KILL QUERY → IX37.15a; SHOW STATS/DIAGNOSTICS → IX37.8d. | ✅ |
IX37.8d 1.x: SHOW STATS und DIAGNOSTICS |
Rest aus IX37.8c: `SHOW STATS` und `SHOW DIAGNOSTICS` mit den Modulen und Werten von 1.x (runtime, queryExecutor, write, database, shard, tsm1_* …), soweit KuonenSQL sie hat; heute nur httpd, build und system. Erledigt 2026-10-24, gemessen an 1.11 (Fixture stats-v1). `SHOW STATS` hat die Module von 1.11 mit ihren Tags und Spalten: runtime, queryExecutor, database{database}, localStore, write, subscriber, cq und httpd{bind}. Die Werte sind die von KuonenSQL: - runtime aus .NET (Go-Eigenes 0); - Abfragen, Schreiben, CQs und HTTP gezählt (InfluxZaehler); - numMeasurements und numSeries aus dem Katalog, gleich wie am Orakel. `SHOW DIAGNOSTICS` hat build, config-*, network, runtime und system mit den eingestellten Werten. FOR 'modul' wählt ein Modul, ein unbekanntes gibt nichts. Nicht da: shard und tsm1_* (keine TSM-Engine, die Shards sind Partitionen) sowie indexes. Test InfluxVerwaltungV1Tests.Laufwerte_mit_den_Modulen_von_1x, Lauf Influx, Flux, Beispielkatalog 174/174. Sabotage ok (Schreibzähler aus → rot). | ✅ |
IX37.8e Befund: UPDATE/DELETE mit WHERE verlangt SELECT |
Befund aus IX37.8b (am Orakel): `UPDATE dbo.t SET a = 7 WHERE a = 6` meldet einem Benutzer mit INSERT/UPDATE, aber ohne SELECT, 229 auf SELECT (die Spalten in WHERE und rechts von SET werden gelesen). `UPDATE dbo.t SET a = 8` ohne Lesen geht. KuonenSQL prüft beim UPDATE/DELETE nur das Recht der Anweisung. Gilt ebenso für DELETE … WHERE und MERGE; über alle Zugänge (T-SQL, MariaDB, PostgreSQL) am jeweiligen Orakel messen. Erledigt 2026-10-24, am Orakel gemessen (SQL Server 2025 kq37rt, PostgreSQL 17 und MariaDB 11.8 in den Referenzcontainern). Ein UPDATE oder DELETE, das Spalten seines Ziels liest (WHERE, rechts von SET), verlangt SELECT: - ohne SELECT 229 (PostgreSQL über denselben Weg `permission denied for table`); - mit Spaltenrechten 230 für die erste fehlende Spalte; - bei MariaDB 1143 mit der ersten gelesenen Spalte, auch ganz ohne Spaltenrecht. Ohne gelesene Spalte geht es ohne SELECT. OUTPUT war schon abgedeckt. MERGE prüfte bisher gar keine Rechte. Jetzt prüft es das Recht jeder Aktion (INSERT/UPDATE/DELETE) und SELECT auf das Ziel. Tests LeserechtDmlTests (T-SQL über die Engine, MariaDB über den Draht). Lauf Recht, Berechtig, Merge, Grant, Sicherheit, Spalten, Prinzipal 989/989. Sabotage ok (Leseprüfung aus → 2 rot; SELECT im MERGE weg → rot). | ✅ |
IX37.9 1.x: Aufbewahrung und Continuous Queries |
Hintergrunddienst, der Punkte älter als die Dauer der Aufbewahrungsrichtlinie löscht (Takt wie gemessen, nie im Schreibpfad); `CREATE CONTINUOUS QUERY … BEGIN SELECT … INTO … GROUP BY time(…) END` mit `RESAMPLE EVERY … FOR …`, Ausführung im Takt, Nachholen nach Neustart; `SELECT … INTO` (auch `:MEASUREMENT` und Rückschreiben der Tags). Beim Wiederanlauf und bei `RESTORE LOG` nichts doppelt (wie PR27.6d). **Erledigt 23.10.2026:** SELECT INTO wie 1.11 (Tags/Felder, :MEASUREMENT, written), CQs gespeichert und gezeigt wie 1.x (normalisiert), Takt 1 s nach continuous_querier (erstes Fenster nur gemerkt; nach Neustart kein Nachholen — wie 1.x), Aufbewahrung alle 30 min nach Shard-Gruppen, alte Punkte beim Schreiben verworfen; cq-v1 61/61, Zeittests nach Messung. Rest IX37.9a. | ✅ |
IX37.9a 1.x: Shard-Gruppen sichtbar |
`SHOW SHARDS` und `SHOW SHARD GROUPS` zeigen wie 1.x die Shard-Gruppen je Datenbank und Richtlinie (aus den vorhandenen Zeiten abgeleitet: Beginn/Ende/Ablauf, fortlaufende ids), `DROP SHARD id` löscht die Punkte der Gruppe. Am Orakel messen (cqzeit R5 zeigt das Format, auch `_internal`). Erledigt 2026-10-23: Gruppen im Katalog `influx.shardgruppen` (id, rp, beginn, ende). Sie entstehen beim Schreiben (1.x/2.x) für jeden Punkt ausserhalb einer bestehenden Gruppe der Richtlinie, abgerundet wie Go ab dessen Nullzeit (Wochen beginnen am Montag), mit fortlaufender Kennung über alle Datenbanken. `SHOW SHARDS`/`SHOW SHARD GROUPS` zeigen sie wie 1.x (expiry_time leer bzw. Ende plus Dauer). `DROP SHARD` löscht die Punkte der Gruppe, `shard not found` wenn es sie nicht gibt. Aufbewahrung und `DROP RETENTION POLICY` nehmen die Gruppen mit. Fixture shards-v1, 21/21 gleich. | ✅ |
IX37.9b Kern: Dateigruppen und Dateien |
Kern (Entscheid Marc 23.10.2026: Shards als Partitionen auf benannten Dateigruppen): `ALTER DATABASE … ADD FILEGROUP | ADD FILE … TO FILEGROUP | REMOVE FILE | REMOVE FILEGROUP | MODIFY FILEGROUP … DEFAULT | NAME =`, Dateigruppen ohne Datei, `CREATE TABLE … ON dateigruppe` (1921), Einfügen in eine Dateigruppe ohne Datei (622), nicht leer (5042), Meldungen 5021/5044, Partitionsschema mit unbekannter Dateigruppe (208); `sys.filegroups`, `sys.data_spaces`, `sys.database_files`, `sys.indexes.data_space_id`. Am Orakel SQL Server 2025 gemessen (kq37fg). Erledigt 2026-10-23 (Katalog und Befehle; die eigene Datei je Dateigruppe folgt mit IX37.9c): Dateigruppen sind eine eigene Liste der Datenbank (Kennung = data_space_id, PRIMARY 1) samt Standard-Dateigruppe; ALTER DATABASE ADD FILEGROUP, ADD [LOG] FILE … TO FILEGROUP (ohne: PRIMARY), REMOVE FILE, REMOVE FILEGROUP, MODIFY FILEGROUP DEFAULT | NAME mit den Fehlern und Meldungen des Orakels (5035, 1921, 1828, 622, 5042, 5014, 5009, 5020, 5045, 5012, 208; 5044, 5046, 5021). CREATE TABLE … ON dateigruppe; eine Tabelle ohne ON kommt in die Standard-Dateigruppe; sys.filegroups, sys.data_spaces, sys.database_files, sys.indexes.data_space_id und sys.destination_data_spaces zeigen die Kennungen. Test DateigruppenTests (18). | ✅ |
IX37.9c Kern: Ablage je Dateigruppe |
Kern: eigene Ablage je Dateigruppe. Der Kontrollpunkt schreibt die Zeilen jeder Dateigruppe in ihre eigene Datei (neben `<db>.mdf`, Pfad aus `ADD FILE`), eine partitionierte Tabelle je Partition in die Datei der Dateigruppe ihrer Partition; das Laden setzt sie wieder zusammen. Kontrolldatei, Wiederanlauf, BACKUP/RESTORE und Kopien (H20) ziehen mit. Erledigt 2026-10-23: Jede Dateigruppe mit Datei hat ihre eigene Ablage `<db>.<gruppe>.ndf` neben `<db>.mdf` (Kopf und Kontrollpunktnummer wie die Datendatei). Der Kontrollpunkt schreibt die Zeilen einer Tabelle in ihrer Dateigruppe und einer partitionierten je Zeile in die Datei der Gruppe ihrer Partition; die primäre Datei behält Katalog, PRIMARY-Zeilen und Grossobjekte. Die Kontrolldatei nennt je Datenbank die Gruppendateien (Umbenennen nach einem Absturz, verwaiste Dateien weg); das Laden hängt ihre Zeilen an, fehlt eine, startet die Datenbank nicht (5120). Kopien übertragen auch `.ndf`; RESTORE übernimmt Dateien, Dateigruppen und die Standard-Dateigruppe. Tests DateigruppenAblageTests (3). | ✅ |
IX37.9d Kern: Partitionen ändern, leeren, umhängen |
Kern: `ALTER PARTITION FUNCTION … SPLIT RANGE | MERGE RANGE` (7710, 7715), `ALTER PARTITION SCHEME … NEXT USED`, `TRUNCATE TABLE … WITH (PARTITIONS (n, a TO b))` (7722, 7729), `ALTER TABLE … SWITCH [PARTITION n] TO … [PARTITION m]` (4904, 4938, 4939, 4943, 4950, 4982, 1088). Am Orakel gemessen (kq37pt, kq37sw). Erledigt 2026-10-23: ALTER PARTITION SCHEME … NEXT USED [g] (die nächste Gruppe hinter den Partitionen), ALTER PARTITION FUNCTION … SPLIT RANGE (die neue Seite — bei RIGHT rechts, bei LEFT links — in die nächste Gruppe; 7710, 7721) und MERGE RANGE (die Gruppe der wegfallenden Seite frei, NEXT USED bleibt; 7715), TRUNCATE TABLE … WITH (PARTITIONS (n, a TO b)) (7722, 7729), ALTER TABLE … SWITCH [PARTITION n] TO … [PARTITION m] [WITH (…)] mit den Prüfungen des Orakels (1088, 4955, 4950, 4943, 4938, 4939, 4904, 4905, 4982 über die CHECK-Einschränkung der Quelle). TRUNCATE und SWITCH über eine neue Ablage (ROLLBACK nimmt beides zurück), der Wiederanlauf spielt alles aus dem Protokoll ab. Nachtrag IX37.9b: die Dateigruppe einer Tabelle steht jetzt im Katalogabzug. Tests PartitionsaenderungTests (5). Nachtrag 2026-10-24 (Volltest): Der SWITCH aus IX37.9d hatte den älteren aus PR27.16t verdrängt; damit fehlten 4942, 4944, 4985, 4913, 4947, 4971 und die Warnung 4903. Jetzt gibt es einen Weg mit der Reihenfolge des Orakels: 4943, 4938/4939, 4913, 4904/4905, 4942/4944/4985, 4947, 4971. Eine CHECK-Einschränkung des Ziels nur auf der Partitionsspalte gilt bei einer Partition als Quelle als eingehalten, wenn deren Grenzen sie einhalten; sonst kommt 4972 (`t <= 199` gegen [100, 200) ebenfalls 4972, weil das Orakel die Grenzen vergleicht). Tests: UmschaltenTests +3, PartitionsaenderungTests +3 Fälle. Sabotage ok (4972 aus → rot). | ✅ |
IX37.9e Influx: Shards als Partitionen auf Dateigruppen |
Influx 1.x/2.x: Shards als Partitionen auf benannten Dateigruppen — je Richtlinie eine Partitionsfunktion auf `time` (Grenzen an den Anfängen der Shard-Gruppen) und ein Schema, je Shard-Gruppe eine Dateigruppe mit Datei (`<rp>_<Beginn>`); jede Messung der Richtlinie liegt auf dem Schema. Neue Gruppe: Dateigruppe anlegen, NEXT USED, SPLIT RANGE; `DROP SHARD` und die Aufbewahrung leeren die Partition (`TRUNCATE … WITH (PARTITIONS)`) und geben Dateigruppe und Grenze frei. Bestehende Ablagen werden beim ersten Schreiben umgestellt. Erledigt 2026-10-24: Bei 1.x und 2.x liegt jede Messung auf dem Partitionsschema `influx_<rp>` (Funktion RANGE RIGHT auf `time`, bigint). Jede Shard-Gruppe bekommt beim ersten Punkt ihre Dateigruppe `influx_<rp>_JJJJMMTT` (unter einem Tag `_JJJJMMTT_HHmm`) mit Datei `.ndf`, dazu NEXT USED und SPLIT RANGE am Gruppenbeginn. Messungen von vor IX37.9e kommen ohne Umschreiben auf das Schema. `DROP SHARD`, die Aufbewahrung und `DROP RETENTION POLICY` leeren mit TRUNCATE … WITH (PARTITIONS), danach MERGE RANGE und REMOVE FILE/FILEGROUP. DROP RETENTION POLICY entfernt zusätzlich Schema und Funktion. V3 bleibt ohne Partitionen. Kernbefunde nebenbei: - ALTER TABLE ADD, sp_rename (Tabelle, Spalte) und der Schemawechsel verloren Partitionsschema und Dateigruppe (am Orakel bleiben sie, auch beim Umbenennen der Partitionsspalte). Neu übernimmt `TableSchema.MitAblage` sie. - `sys.partition_range_values.value` war kein echtes sql_variant (CAST schlug fehl). - `Partitionsfunktion.Nummer` sucht binär. Tests: InfluxShardpartitionenTests, PartitionsaenderungTests.Spalte_dazu_und_Umbenennen_…; Lauf Influx, Flux, Partition, Dateigruppe, Rename, AlterTable, Katalog 522/522. Sabotage ok (Partition ausgelassen → rot; MitAblage beim ALTER weg → 2 rot). | ✅ |
IX37.9f Kern: Tablespaces von MySQL, MariaDB und PostgreSQL auf Dateigruppen |
Rest aus IX37.9b (Frage Marc, 24.10.2026): Die Dateigruppen gibt es am T-SQL- und am KSQL-Zugang (DateigruppenTests.Am_KSQL_Zugang_…). Das Gegenstück der anderen Zugänge fehlt noch: Tablespaces von MySQL 8.4/MariaDB (`CREATE TABLESPACE … ADD DATAFILE`, `CREATE TABLE … TABLESPACE x`, information_schema.FILES) und von PostgreSQL (`CREATE TABLESPACE … LOCATION`, `… TABLESPACE x`, pg_tablespace). Sie sollen auf Dateigruppen abgebildet werden, am jeweiligen Orakel gemessen. Bis dahin kommt eine Tabelle von dort in die Standard-Dateigruppe. | ⬜ |
IX37.10 2.x: HTTP-API ohne Flux |
`POST /api/v2/write?org=&bucket=&precision=` (auch `orgID`, `bucketID`), Fehler als `{"code","message"}`; Einrichtung `/api/v2/setup`; Organisationen, Buckets (mit Aufbewahrungsregel wie IX37.9), Token und Berechtigungen (`/api/v2/authorizations`), Benutzer; `/api/v2/delete` mit Zeitbereich und Prädikat; die 1.x-Kompatibilität `/query` und `/write` über DBRP-Zuordnung (`/api/v2/dbrps`) mit dem InfluxQL aus IX37.6 bis IX37.8; explizites Schema je Bucket (`/api/v2/buckets/…/schema/measurements`) annehmen oder ablehnen wie gemessen. Werkzeug `influx` 2.x für `write`, `query` (über v1), `bucket`, `auth`. **Erledigt 23.10.2026:** Bucket = Datenbank (Entscheid Marc), Katalog master.influx2; Einrichtung, Orgs, Buckets, Benutzer, Token mit Rechten, DBRP, /api/v2/write, /api/v2/delete, 1.x-Wege über DBRP wie 2.7; explizites Schema gibt es in OSS nicht (404, gemessen); api2-v2 98/98, Zugangstest über alle SQL-Zugänge. Rest IX37.10a (Werkzeug influx). | ✅ |
IX37.10a 2.x: Abnahme mit dem Werkzeug influx |
Das Werkzeug `influx` 2.x (aus dem Abbild `influxdb:2.7`) gegen einen laufenden KuonenSQL mit `KUONENSQL_INFLUX_FASSUNG=2`: `influx write`, `influx query` nur über v1 (`influx v1 shell`), `influx bucket list/create/delete`, `influx auth list/create`, `influx v1 dbrp list/create`; Abweichungen als Befunde beheben. Gehört mit IX37.16 zusammen. Erledigt mit IX37.16: influx 2.7 gegen KuonenSQL (bucket create/list, write, query, auth create/list, v1 dbrp list) läuft; Befund `/api/v2/me` für sa behoben. | ✅ |
IX37.11 2.x: Flux (Teilmenge) |
`POST /api/v2/query` mit Flux, Antwort als annotiertes CSV (`#datatype`, `#group`, `#default`, eine Tabelle je Gruppe) exakt wie das Orakel. Die Teilmenge, die Grafana und die Telegraf-Dashboards brauchen: `from`, `range`, `filter`, `keep`/`drop`, `group`, `aggregateWindow` (mit `fn`, `createEmpty`), `mean`/`sum`/`min`/`max`/`last`/`first`/`count`, `map`, `pivot`, `sort`, `limit`, `yield`, `v.timeRangeStart`/`v.windowPeriod`. Weiteres Flux nur auf Wunsch (InfluxData führt Flux in 3.x nicht weiter); nicht unterstützte Funktionen mit der Meldung des Orakels für unbekannte Bezeichner. Umgesetzt (Welle F): `POST /api/v2/query` mit Flux (vnd.flux oder JSON mit dialect, extern wie Grafana, now), eigener Leser (Stellen wie Flux, `undefined identifier` vor dem Lauf) und Ausführer über Tabellenströme: from/range (Bucket = Datenbank, Tabellen je Serie und Feld, filter auf _measurement eingeengt), filter, keep/drop/rename, group (by/except), aggregateWindow (every, period, offset, fn, createEmpty, timeSrc), mean/sum/count, min/max/first/last, map (mit/ohne with), pivot, sort, limit, yield, fill, difference, timeShift, toFloat/toInt/toString/toBool, int/float/string/bool/uint/time, now, option v. Annotiertes CSV mit CRLF, #datatype/#group/#default, Zahlen wie Go 'f' -1. Gemessen flux-v2 (51): 49 gleich, Reste IX37.11a. Abnahme: Flux liest, was T-SQL, KSQL, PG, MariaDB und MySQL ändern (InfluxZugaengeTests). | ✅ |
IX37.11a 2.x: Flux über die Teilmenge hinaus |
Offen aus IX37.11: Meldungen des Flux-Lesers bei Syntaxfehlern wörtlich (flux-v2 F25), Reihenfolge mehrerer `yield` (2.x gibt fertige zuerst aus, F23), Paket `influxdata/influxdb/schema` (measurements, tagKeys, tagValues, fieldKeys — der Abfrage-Baukasten von Grafana), `buckets()`, weitere Funktionen nur auf Wunsch (window, quantile/median, stddev, derivative, cumulativeSum, distinct/unique, join/union, to()). Erledigt 2026-10-24: gemessen in drei neuen Folgen am Orakel influxdb:2.7 — flux2-v2 (74 Fälle), die Prüfreihe flux3-v2 (41, erst nach dem Bau gemessen) und flux4-v2 (27, mit Annotationen). **Leser.** Der Flux-Leser ist nach libflux 0.194 nachgebaut (Scanner, Parser, check). Er sammelt alle Fehler und meldet sie wörtlich wie 2.x (`compilation failed: error @1:23-1:36: expected RPAREN, got EOF` …, F25, E1–E17). Die Bedeutungsfehler kommen ebenso gesammelt: unbekannter Bezeichner, unbekanntes Paket, ungültiger Operator. **Mehrere `yield`.** Sie kommen in der Folge von 2.x: geordnet nach dem Text der Operationskennung (`yield10` vor `yield4`). Ein `to()` ohne `yield` heisst `to5`. **Neu:** - das Paket `influxdata/influxdb/schema` (measurements, tagKeys, tagValues, fieldKeys, measurement…, fieldsAsCols). measurements liest ohne Zeit, die übrigen auf Ebene der Shard-Gruppen. - `buckets()`, gruppiert nach organizationID, `array.from` und Texte mit `${…}`; - window (auch `every: inf`), duplicate, median/quantile (t-digest, exact_mean, exact_selector), stddev, spread; - derivative, cumulativeSum, integral, movingAverage, elapsed, distinct, unique, join, union und to(). **Folge der Spalten.** Aggregate, die 2.x nicht in der Ablage rechnet, setzen `_value` ans Ende. `group()` aus der Ablage behält `_start`/`_stop` im Schlüssel. `map` behält die Spaltenfolge nur, wenn 2.x vektorisiert. `pivot` behält Schlüssel- und Zeilenspalten in der Folge des Auftretens. Leere Tabellen haben einen eigenen Kopf. **Nicht nachgebaut.** Bei Tabellen mit weniger als n Zeilen hängt 2.x das Mittel von `movingAverage` nur manchmal als weitere Tabelle an (flux3-v2 V25, flux4-v2 A1x/A3; A2: nie). **Tests.** InfluxFluxTests mit drei neuen Folgen, flux-v2 ohne Ausnahmen. Lauf Influx/Flux/Flight/Beispielkatalog 189/189. Sabotage ok (drei Proben rot). | ✅ |
IX37.12 3.x: HTTP-API |
`POST /api/v3/write_lp?db=&precision=&accept_partial=&no_sync=`, dazu die Schreibwege von 1.x und 2.x am 3.x-Port wie beim Orakel; `GET`/`POST /api/v3/query_sql` und `/api/v3/query_influxql` mit `format=json`, `jsonl`, `csv`, `pretty`, `parquet` (eigener Parquet-Schreiber, nur was das Orakel liefert); Verwaltung `/api/v3/configure/database`, `…/table`, Token (Verwalter- und Ressourcentoken), `…/distinct_cache`, `…/last_cache`; `/health`, `/ping`. Das SQL von 3.x (Apache DataFusion) auf den KSQL-Kern abbilden: Bezeichner wie PostgreSQL, `date_bin`, `date_bin_gapfill`, `locf`, `interpolate`, `selector_first`/`selector_last`/`selector_min`/`selector_max`, `now()`, Systemtabellen `system.queries`, `information_schema`. Werkzeug `influxdb3` für `write`, `query`, `create database`, `create token`. Umgesetzt (Welle E): `write_lp` (precision auto/s/ms/us/ns, accept_partial, Datenbank entsteht beim Schreiben, Fehlerliste mit line_number/original_line), `/write` und `/api/v2/write` am 3.x-Port mit den Fehlerformen von 3.x, `query_sql` und `query_influxql` per GET/POST (JSON-Rumpf, params) in json/jsonl/csv/pretty, `/query` wie 1.x mit den Meldungen von 3.x, `configure/database|table` (GET/POST/DELETE). SQL von DataFusion über den PostgreSQL-Übersetzer mit Suchpfad `iox` (je Messung eine Sicht `iox.<messung>`, auch für T-SQL/KSQL/PG/MariaDB/MySQL lesbar) und einer Vorstufe für date_bin, date_bin_gapfill/locf/interpolate, to_timestamp*, GROUP BY Alias, CAST wie DataFusion, information_schema, SHOW TABLES/COLUMNS, system.*; Fehler wie DataFusion. Zahlen und Zeiten wie 3.x (zahlen-v3). Gemessen sql-v3 (143), zahlen-v3 (9); sql-v3 119/143, zahlen/lp/lp2/influxql/grundlagen-v3 gleich bis auf die benannten Reste (IX37.12a–e). Abnahme: über write_lp Geschriebenes ist über alle fünf SQL-Zugänge les- und änderbar (InfluxZugaengeTests). | ✅ |
IX37.12a 3.x: Zeit unter 100 ns in SQL |
Die Sichten `iox.<messung>` zeigen `time` als `datetime2(7)` (100 ns); 3.x rechnet in Nanosekunden (sql-v3 S29–S31, grundlagen-v3 S2/S3: `.123456789` wird `.123456800`). Gespeichert ist die Zeit genau (`time bigint`); fehlt ein Zeittyp mit ns in der Engine oder ein Weg, `time` als bigint durch die Abfrage zu tragen und erst in der Ausgabe als Zeit zu schreiben. Auch `to_timestamp(n)` über `timestamp` (µs). Erledigt 2026-10-24: SQL von 3.x zeigt die Zeit auf die Nanosekunde, wie gemessen in sql-v3 S11, S29–S31 und grundlagen-v3 S2/S3 (`.123456789`, vorher `.123456800`). Ein Zeitpunkt in der Engine trägt jetzt den Rest unter 100 ns mit (`SqlValue.Nanorest`). `DATEADD(NANOSECOND, …)` auf datetime2 legt ihn neben die Ticks; diese sind gerundet wie SQL Server. Vergleich, Text und TDS kennen den Rest nicht, für T-SQL ändert sich also nichts. Die Sichten `iox.<messung>` rechnen `time` aus `[time]`, nicht aus `_zeit`, das auf 100 ns gerundet abliegt. Der Rest geht so durch Auswahl, Sortierung und Filter. Die Ausgabe von 3.x (JSON, CSV, pretty, Flight) rechnet ihn ein. Tests: InfluxApiV3Tests mit sql-v3 und grundlagen-v3 ohne die bisherigen Ausnahmen S11, S29–S31, S2, S3. Lauf Influx, Flux, Beispielkatalog, Date, Datum, Zeit, Flight 1295/1295. Sabotage ok (Rest nicht eingerechnet → 2 rot). | ✅ |
IX37.12b 3.x: Ausgabe als Parquet |
`format=parquet` an `query_sql`/`query_influxql` antwortet heute 405 (KuonenSQL). Eigener Parquet-Schreiber (Thrift compact, PLAIN, eine Zeilengruppe) und ein Prüfleser im Test, der zuerst eine Parquet-Datei des Orakels liest. Erledigt 2026-10-24: `format=parquet` an `query_sql` und `query_influxql` (POST und GET) schreibt Parquet, gemessen in parquet-v3 (P1–P7, je mit dem JSON-Zwilling J1–J7). Aufbau wie 3.x: eine Zeilengruppe, Wurzel `arrow_schema`, nie-NULL-Spalten REQUIRED, Text BYTE_ARRAY/STRING, Zeit INT64/TIMESTAMP(NANOS, nicht UTC), UInt64 mit INTEGER(64, unsigned), `ARROW:schema` in den Metadaten; ein leeres Ergebnis ist ein leerer Rumpf. Anders als 3.x (ZSTD, Wörterbuch) unkomprimiert und PLAIN; pyarrow liest die Dateien mit denselben Typen und Werten. Nebenbei: Ausdrücke nur aus Literalen und `now()` sind nie NULL (P4), wie in DataFusion. Messwerkzeug und Testfolge halten Parquet als `base64:` fest. Tests: InfluxParquetTests (Prüfleser liest die Fusszeile des Orakels; Fusszeilen und Kopfzeilen wie das Orakel, Werte wie dessen JSON; 200 zufällige Ergebnisse bis 20 Spalten und 300 Zeilen). Lauf Influx/Flight/Flux/Beispielkatalog/Sortierung 426/426. Sabotage ok (Definitionsstufen, STRING-Typ → rot). | ✅ |
IX37.12c 3.x: SQL-Funktionen und Namen von DataFusion |
Noch nicht wie DataFusion (sql-v3, zahlen-v3): `selector_first|last|min|max` (Struct mit value/time), `arrow_typeof`, `EXPLAIN` (405), `CAST('NaN'|'inf' AS DOUBLE)`, Spaltennamen ohne Alias (`Int64(1)`, `count(*)`), „Did you mean“ in Meldungen, Text in UNION/ORDER BY binär sortiert (S19). Erledigt 2026-10-24: SQL von 3.x benennt, typisiert und wählt wie DataFusion, gemessen in sql-v3, zahlen-v3 und der neuen Folge funktionen-v3 (28 Fälle). Spalten ohne Alias heissen wie in DataFusion (`Int64(1)`, `count(*)`, `sum(cpu.usage)`, `cpu.usage * Int64(2)`, `(- cpu.n)`, `CAST(cpu.n AS Float64)`); zwei gleiche Namen weist 3.x ab, KuonenSQL auch. `arrow_typeof` nennt den Typ von Arrow (Tag `Dictionary(Int32, Utf8)`, `Null`), auch im WHERE. `selector_first|last|min|max(wert, zeit[, …])` gibt die Struktur `{value, time, other_1…}`, `['value']` ein Feld. `EXPLAIN SELECT <Literale>` zeigt den Plan von DataFusion. Eine unbekannte Funktion schlägt die nächste der 303 Funktionen von 3.x vor (`Did you mean 'sum'?`). `CAST('NaN'|'inf'|'-inf' AS DOUBLE)`, `CAST(1735689600 AS TIMESTAMP)` (Sekunden) und `avg` in Float64 rechnen wie 3.x. Text vergleicht und sortiert binär (`Bern` vor `a`). Dazu ein Befund im Kern (T-SQL wie SQL Server 2025): eine abgeleitete Tabelle verlor die Sortierung aus `x COLLATE s` und aus UNION; `ORDER BY` und `MIN` darüber folgen ihr jetzt. Tests: InfluxApiV3Tests (funktionen-v3 neu; sql-v3, zahlen-v3 ohne die bisherigen Ausnahmen bis auf E7), AbgeleiteteSortierungTests (T-SQL, KSQL). Lauf Influx/Flight/Beispielkatalog/Sortierung 496/496. Sabotage ok (3 Proben rot). Rest: IX37.12g (Pläne über Tabellen, `information_schema.routines`, Name eines Intervalls), IX37.12h (PostgreSQL-Übersetzer). | ✅ |
IX37.12g 3.x: Pläne über Tabellen, routines, Name eines Intervalls |
Rest aus IX37.12c (gemessen funktionen-v3). `EXPLAIN` über Tabellen sowie `EXPLAIN ANALYZE` und `EXPLAIN VERBOSE` (X1–X3) antworten noch 405. Der physische Plan von 3.x hängt an Partitionen und Optimierer (`RepartitionExec: partitioning=RoundRobinBatch(32)`). Ebenso offen: `information_schema.routines` mit den 453 Einträgen von 3.x (F5, F6; heute die Liste von PostgreSQL) und der Name eines Intervalls ohne Alias (N4: `date_bin(IntervalMonthDayNano("IntervalMonthDayNano { months: 0, days: 0, nanoseconds: 3600000000000 }"),cpu.time)`). Erledigt 2026-10-24 (ohne die Pläne über Tabellen, Rest IX37.12i): gemessen in routinen-v3 und plaene-v3. `information_schema.routines` (453), `information_schema.parameters` (3112) und `SHOW FUNCTIONS [LIKE …]` (914) zeigen die Funktionen von 3.x samt Beschreibungen, Typen (UInt64, UInt8, Boolean) und Listen; die Daten liegen als Referenzdaten bei (`tools/influx/datafusion-funktionen.py`). Intervalle: Name ohne Alias (`IntervalMonthDayNano(…)`, auch in `date_bin`), Wert als Text wie Arrow (`1 hours 30 mins`, `5.000000000 secs`, leer bei null), `arrow_typeof` `Interval(MonthDayNano)`; `TIMESTAMP '…'` heisst wie Text. `pretty` verteilt mehrzeilige Zellen auf Zeilen; `EXPLAIN FORMAT INDENT`. SQL von 3.x läuft jetzt ganz im Dialekt von PostgreSQL (NULL bei ASC zuletzt wie DataFusion); `sum` über Ganzzahlen bleibt Int64. Tests: InfluxApiV3Tests (routinen-v3, plaene-v3 neu; funktionen-v3 jetzt mit N4, F5, F6; SHOW FUNCTIONS LIKE als Menge, weil 3.x je Lauf anders ordnet). Lauf Influx/Flight/Beispielkatalog/PostgreSQL 1417/1417. Sabotage ok (Sekunden ohne neun Stellen → rot, ohne Dialekt → rot). | ✅ |
IX37.12h PostgreSQL-Übersetzer: avg in Klammern |
Befund aus IX37.12c. Der Übersetzer des PostgreSQL-Zugangs zerlegt ein `avg` in Klammern falsch: `SELECT (avg(1))` wird zu `pg_numeric_div ( sum ( cast ( 1 as decimal(38, 0) ) ) ) , count_big ( 1 ) ) )` und scheitert mit 102. Ohne Klammer stimmt es. SQL von 3.x umgeht es, indem es dort keine Klammer setzt. Zu messen am Orakel PostgreSQL, dann im Übersetzer zu beheben. Erledigt 2026-10-24: am Orakel postgres:17 gemessen — `(avg(1))` ist `1.00000000000000000000` (numeric), `((avg(x)))` und `(avg(x) + 1)` rechnen wie ohne Klammer, `(avg(x) OVER ())` ebenso. Der Knoten eines Aufrufs in Klammern reicht über die Klammern; der Übersetzer nahm die schliessende als Teil des Fensters. Jetzt bleiben die Klammern aussen stehen, und das Fenster ist nur `OVER …`. Tests: PgAggregattypenTests (4 neue Fälle). Lauf PostgreSQL 1307/1307. Sabotage ok (Klammer hinten weg → 2 rot). | ✅ |
IX37.12i 3.x: EXPLAIN über Tabellen (logischer Plan) |
Rest aus IX37.12g (gemessen plaene-v3 P1–P11, routinen-v3 X4–X6, funktionen-v3 X1). `EXPLAIN` über Tabellen antwortet 405. Der logische Plan von DataFusion ist fest und nachbaubar. Er zeigt `Projection`, `Filter`, `Sort` (`ASC NULLS LAST`, `fetch=`), `Limit`, `Aggregate: groupBy=[[…]], aggr=[[…]]` und `TableScan: cpu projection=[…], partial_filters=[…]`. Dazu die Regeln des Optimierers: Projektion weglassen, Filter und `fetch` in den Scan, Literale angepasst (`Dictionary(Int32, Utf8("a"))`, `Float64(1)`, `TimestampNanosecond(…, None)`), `count(*)` als `count(Int64(1)) AS count(*)`. Der physische Plan dagegen hängt am Speicherstand von 3.x: ein oder zwei Chunks, `input_partitions` 1 oder 2 bei derselben Abfrage. Dort zeigt KuonenSQL den eigenen Plan. Zu bauen: der logische Plan für Abfragen über eine Tabelle. Erledigt 2026-10-24: `EXPLAIN` einer Auswahl über eine Tabelle zeigt den logischen Plan wie DataFusion: 15 Pläne zur Herleitung und eine Prüfreihe plaene2-v3 mit 18 neuen Plänen (14 stimmten sofort, 4 Regeln nachgezogen). Gebaut sind Projektion, Filter, Aggregat, Sortierung, LIMIT/OFFSET und der Scan mit `partial_filters` und `fetch`. Dazu Typangleichung der Literale, `count(*)` als `count(Int64(1)) AS count(*)`, `x = true` als `x` und `lower` über einem Tag als `CAST(… AS Utf8View)`. Der physische Plan zeigt den T-SQL-Text, den KuonenSQL ausführt; der von 3.x hängt am Speicherstand. Joins, Unterabfragen, HAVING und DISTINCT antworten weiter 405. Tests: Logische_Plaene_wie_das_Orakel (33 Pläne). Lauf 1421/1421. Sabotage ok (Projektion nie weggelassen → 3 rot; Tag-Literal ohne Dictionary → 2 rot). Rest: IX37.12j. | ✅ |
IX37.12j 3.x: EXPLAIN ANALYZE/VERBOSE, Pläne über mehrere Tabellen |
Rest aus IX37.12i. Noch offen sind `EXPLAIN ANALYZE` (Plan mit Messwerten, funktionen-v3 X2) und `EXPLAIN VERBOSE` (jeder Schritt des Optimierers, X3). Ebenso der logische Plan für Abfragen über mehr als eine Tabelle, mit Unterabfragen, HAVING oder DISTINCT. Diese antworten heute 405. Erledigt 2026-10-24: gemessen in plaene3-v3 (20 Fälle) und der Prüfreihe plaene4-v3 (12, nach dem Bau gemessen). **Logische Pläne wie DataFusion.** - DISTINCT als Aggregate, HAVING als Filter über der Gruppierung, `count(DISTINCT x)` mit `alias1`. - Ein Alias der Tabelle und WITH als SubqueryAlias. - Unterabfragen im FROM in die äussere gezogen; ein WHERE über einer Gruppierung wird HAVING, eine Teilauswahl verkürzt die innere. - UNION ALL als ein Union (verschachtelte flach), UNION mit Aggregate. - Inner und Left Join, `IN (SELECT …)` als LeftSemi Join mit `__correlated_sq_1`, eine skalare Unterabfrage als Left Join mit `__scalar_sq_1`. **`EXPLAIN VERBOSE`.** - Ohne Tabelle alle Schritte, auch die physischen samt Statistik und Schema. - Über einer Tabelle mit oder ohne WHERE die logischen Schritte (type_coercion, simplify_expressions, push_down_filter, optimize_projections; ein zweiter Optimiererlauf nur nach einer Änderung). - Der physische Teil über Tabellen zeigt den eigenen Plan. - VERBOSE über anderen Formen antwortet 405. **`EXPLAIN ANALYZE [VERBOSE]`.** Dieselben Arten von Zeilen wie 3.x (Plan with Metrics, Plan with Full Metrics, Output Rows, Duration), mit den Messwerten des eigenen Laufs. **Tests.** InfluxApiV3Tests (Logische_Plaene_wie_das_Orakel mit 22 Plänen mehr, Explain_verbose_und_analyze_wie_das_Orakel). Lauf Influx/Flux/Flight/Beispielkatalog 192/192. Sabotage ok (Union nicht flach → rot, immer zwei Optimiererläufe → rot). | ✅ |
IX37.12d 3.x: _internal und weiches Löschen |
3.x zeigt die Datenbank `_internal` und behält gelöschte Datenbanken/Tabellen unter `name-<Zeitstempel>` (deleted=true, sql-v3 D4–D10, I4, V4, V5, S33). KuonenSQL löscht hart und zeigt kein `_internal` — entscheiden, ob das nachgebaut werden soll (Marc). Erledigt 2026-10-23 (Entscheid Marc: nachbauen; gemessen loesch-v3, 41/43 Blöcke gleich, die übrigen zeigen Rechner und Token des Orakels). `_internal` ist immer die erste Datenbank, mit den Systemtabellen von 3.x (`system.databases`, `system.tables`, `nodes`, `tokens`, `generation_durations`, `plugin_files` …); Anlegen und Schreiben sind ein Namensfehler, Löschen 500. Gelöscht wird weich: Datenbank und Tabellen heissen `name-JJJJMMTTThhmmss` (echt umbenannt, über alle Zugänge sichtbar) und sind in `influx.geloescht` markiert. Eine gelöschte Datenbank ist aus den Listen verschwunden, InfluxQL SHOW DATABASES zeigt sie mit deleted=true; Schreiben dorthin 400, nochmals Löschen 409. Endgültig weg nach 72 h oder `hard_delete_at` (Aufräumen jede Minute im Hintergrund von 3.x). Eine unbekannte Datenbank liest sich wie eine leere, eine Tabelle darin gibt 404. Listen in der Reihenfolge des Anlegens (sql-v3 V4). Dabei behoben: `sp_rename N'schema.t', N'neu'` liess die Tabelle in dbo landen (am Orakel: bleibt im Schema). sql-v3 D4–D6, D10, I4, V4, V5, S33, S35 und grundlagen-v3 A3, A4 werden jetzt verglichen. | ✅ |
IX37.12e 3.x: Meldungen des InfluxQL-Lesers |
Lesefehler und einige Anweisungsfehler von InfluxQL meldet 3.x mit seinem eigenen Leser (nom: `invalid SELECT statement, expected field at pos 6`, `Parsing Error: Nom(...)`, `is not a valid timestamp`, Regex-Fehler 500; influxql-v3 E1–E4, E10–E12, S21). KuonenSQL meldet die Texte von 1.x hinter dem Vorspann von 3.x. Erledigt 2026-10-24, gemessen an 3-core: influxql-v3 E1–E4, E10–E12, S21 und die neue Fixture lesefehler-v3 L1–L10. Die Lesefehler von InfluxQL meldet KuonenSQL wie der eigene Leser von 3.x (Influx3Lesefehler): - Ohne Feld: `invalid SELECT statement, expected field at pos P`; ohne Quelle: `invalid FROM clause, …`. - Bedingung nach WHERE angefangen: `invalid conditional expression`; leeres ORDER BY: `invalid ORDER BY, expected ASC, DESC or TIME`. - Sonst der Rest ab dem Klauselwort: `invalid InfluxQL statement at pos P. Parsing Error: Nom("Rest", Tag)`. Das gilt für ein unbekanntes Wort, ein leeres WHERE, GROUP BY oder LIMIT, eine Klausel an falscher Stelle, ein Komma ohne Feld und SHOW allein (Many1). - `/*` ohne Ende ist ein Kommentarfehler. - Ein kaputter regulärer Ausdruck gibt 500 mit der Meldung von Rust regex (unclosed/unopened group, unclosed character class) samt Zeiger. - Ein Text als Zeitpunkt scheitert bei `split condition … is not a valid timestamp`. Grundlage ist die Stelle und das Erwartete aus dem Lesefehler von 1.x. Tests: InfluxApiV3Tests.Folge_wie_das_Orakel mit influxql-v3 (ohne die bisherigen Ausnahmen) und lesefehler-v3; Lauf Influx, Flux, Beispielkatalog 175/175. Sabotage ok (Abbildung aus → 2 rot). | ✅ |
IX37.12f 3.x: Token-Verwaltung und influxdb3 |
Aus IX37.12 offen: `/api/v3/configure/token/admin` (Verwaltertoken anlegen, neu erzeugen) und Ressourcentoken mit Rechten je Datenbank (heute meldet sich 3.x mit `Anmeldename:Kennwort` bzw. dem Kennwort an). Abnahme mit dem Werkzeug `influxdb3` (write, query, create database, create token) unter IX37.16. Erledigt 2026-10-24: Token-Verwaltung von 3.x wie influxdb:3-core (Fixture token-v3). - `POST /api/v3/configure/token/admin` (_admin, Kennung 0, ein zweites Mal 409) und `…/admin/regenerate` (das alte Geheimnis gilt nicht mehr). - `POST …/token/named_admin` mit token_name und expiry_secs (409, 400 serde) sowie `DELETE …/token?token_name=` (404 unbekannt, 405 für _admin). - `system.tokens` mit den 10 gemessenen Spalten. Ein Token `apiv3_…` meldet sich als die Anmeldung an, die es angelegt hat. Gespeichert ist nur der SHA-512 in master (Schema influx3); ein abgelaufenes Token gibt 401. Token verwaltet nur ein Verwalter (sonst 403). Bewusst anders: ohne Anmeldung legt KuonenSQL kein erstes Verwaltertoken an (401). Ressourcentoken gibt es wie in Core nicht (Enterprise, am Orakel 404). Tests InfluxApiV3Tests.Token_… (2), Lauf Influx, Flux, Beispielkatalog 167/167. Sabotage ok (Hash nie gleich → 2 rot; Ablauf verschoben → rot). Die Abnahme mit influxdb3 bleibt bei IX37.16a. | ✅ |
IX37.13 3.x: Arrow Flight SQL |
gRPC über HTTP/2 am 3.x-Port: Flight SQL (`GetFlightInfo`/`DoGet` für `CommandStatementQuery`, vorbereitete Anweisungen, `GetCatalogs`/`GetDbSchemas`/`GetTables`/`GetSqlInfo`), Arrow-IPC-Ausgabe mit den Typen des Orakels (Zeitstempel in ns, Dictionary-Spalten für Tags), Ticket-Format und Kopfzeile für die Datenbank wie gemessen; Token wie IX37.12. Arrow-IPC-Schreiber und Protobuf-Nachrichten im Eigenbau (kein Paket). Abnahme mit `influxdb3-python`, dem ADBC- und JDBC-Flight-SQL-Treiber und Grafana „FlightSQL“. Umgesetzt (Welle G): HTTP/2 im Eigenbau am 3.x-Port (Vorspann erkannt, ohne TLS oder mit ALPN h2; SETTINGS, HEADERS/CONTINUATION, DATA mit Flusskontrolle, PING, GOAWAY; HPACK mit dynamischer Tabelle und Huffman nach RFC 7541), gRPC-Rahmen, Protobuf, FlatBuffers und Arrow IPC (Schema, RecordBatch; Int64/UInt64/Float64/Boolean/Utf8/Timestamp(ns), Nullbarkeit wie 3.x). Flight: DoGet mit dem JSON-Ticket der Clients von 3.x (sql/influxql, params); Flight SQL: GetFlightInfo/DoGet für CommandStatementQuery (Kopfzeile database), GetCatalogs/GetDbSchemas/GetTables/GetTableTypes, vorbereitete Anweisungen (DoAction), Handshake, ListActions; Fehler als gRPC-Status mit den Meldungen von 3.x. Gemessen mit einem eigenen Flight-Client im Test am Orakel (flight-v3, 18 Aufrufe): 17 gleich. Robustheit: zu grosser Rahmen und kaputter Kopfblock beenden nur die Verbindung. Abnahme: Flight liest, was T-SQL, KSQL, PG, MariaDB und MySQL ändern. Rest IX37.13a. | ✅ |
IX37.13a 3.x: Flight SQL über die Teilmenge hinaus |
Offen aus IX37.13: GetSqlInfo (dense union), DoPut für Parameter vorbereiteter Anweisungen, komprimierte gRPC-Nachrichten, PollFlightInfo, Nachsatz von DataFusion an Lesefehlern (flight-v3 FL8), Ausgabe in mehreren RecordBatches bei grossen Ergebnissen (heute eine). Abnahme mit influxdb3-python, ADBC/JDBC und Grafana FlightSQL unter IX37.16. Erledigt 2026-10-24: gemessen an influxdb:3-core mit pyarrow.flight und dem Testclient (flight-v3 FX1–FX14, FB1–FB6, FY1–FY9). **Flight SQL über die Teilmenge hinaus.** - `GetSqlInfo`: alle 86 Einträge von 3.x als dichte Union (Referenzdaten flightsql_info.json.gz), ausgewählte Kennungen geordnet, unbekannte fallen weg. - `GetXdbcTypeInfo`: fünf Typen; `GetPrimaryKeys`: leer. `GetTables` mit `include_schema`: das Schema je Tabelle von iox (Tags als Wörterbuch, Metadaten von 3.x). - Parameter vorbereiteter Anweisungen über `DoPut`: die erste Zeile der RecordBatch, Spaltenname ohne `$`. Die Antwort `DoPutPreparedStatementResult` trägt ein neues Handle mit den Werten. Das Schema auch mit offenem Platzhalter; der Fehler kommt erst beim DoGet. - Grosse Ergebnisse in mehreren RecordBatches: 600 Zeilen (nach time oder ungeordnet, InfluxQL), 8192 nach einer anderen Spalte; leere ohne RecordBatch. - Der Nachsatz an Lesefehlern (`: sql parser error: Expected: 1`). - gzip und andere Kodierungen: 12 „Content is compressed with `gzip` which isn't supported“. ListFlights, ListActions, GetSchema, PollFlightInfo und DoExchange: 12 „Not yet implemented…“ wie 3.x. **Befund beim Testen, behoben (Engine).** - MERGE prüfte jede Quell- gegen jede Zielzeile; jetzt gleicht ein ON aus Gleichheiten über Eimer ab, mit der vollen Bedingung je Kandidat. - Die Prüfung des Primärschlüssels sucht über die Spalte mit den wenigsten Treffern statt über die führende. - Schreiben von 20000 Punkten über /api/v3/write_lp: vorher quadratisch (8000 Punkte 152 s), jetzt 5 s. **Tests.** InfluxFlightTests (flight-v3 neu gemessen, FL8 wieder verglichen) und MergeindexTests (am Orakel SQL Server 2025 gemessen). Lauf grün. Sabotage je rot: keine Stapel, SqlInfo ungefiltert, kein Nachsatz, Parameternamen mit `$`, Mergeindex aus, Schlüsselprüfung über die erste Spalte, Leerzeichen am Ende im Schlüssel. **Rest:** IX37.13b. | ✅ |
IX37.13b 3.x: Flight SQL, Rest aus IX37.13a |
Rest aus IX37.13a (gemessen an influxdb:3-core): - Ein Text als Parameter gegen eine Zahlenspalte (`n = $1` mit 'x'): DataFusion vergleicht als Text (leeres Ergebnis), KuonenSQL meldet den Fehler der Umwandlung (flight-v3 FX13, ausgenommen). - `parameter_schema` in ActionCreatePreparedStatementResult: 3.x leitet die Typen der Platzhalter aus der Abfrage ab (`$1: string`, `$2: int64`). - `GetTables` mit `include_schema` für die Tabellen von information_schema und system: deren Schema mit den Typen von 3.x (Utf8View, Duration, UInt16, Zeitstempel mit UTC); heute ein leeres Schema. - Grenzen der RecordBatches eines ungeordneten Ergebnisses: in 3.x folgen sie den Stücken der Ablage (599/1 …), KuonenSQL teilt nach 600. Erledigt 2026-10-24: gemessen an influxdb:3-core (probe13b2, vergleich-v3, flight-v3 FV1–FV16 und FX6 über alle Tabellen). **Text gegen Zahl.** DataFusion wandelt einen Text im Vergleich mit einer Zahlenspalte ohne Fehler: `n = '2'` trifft, `n = 'x'` und `n = '2.0'` werden NULL und treffen nichts. Das gilt direkt im SQL und als Parameter (HTTP und DoPut). Gegen einen Wahrheitswert ist es ein Fehler der Typen (`type_coercion … Boolean = Utf8`, `<>` als `!=`). Eine Zahl gegen einen Tag vergleicht als Text. **parameter_schema.** - CreatePreparedStatement liefert die Typen der Platzhalter. Sie kommen aus dem Partner eines Vergleichs, aus IN, BETWEEN, Rechnungen, Funktionen und `time`; leer ohne Platzhalter. - Ohne Partner: 13 „Unable to infer the type of parameter“. Zwei Typen: 3 „Conflicting types“ mit den Metadaten der Spalten. - Fehler beim Vorbereiten heissen „Error while planning query“ (ein Fehler des Schemas: INVALID_ARGUMENT). - Die Reihenfolge der Felder ist am Orakel je Lauf anders; der Test ordnet sie. **GetTables mit include_schema.** Die Schemas aller Tabellen von information_schema und system wie 3.x, mit den Typen Utf8View, UInt8, UInt16, Duration(ns) und Timestamp(ns, UTC). **Nicht nachgebaut:** Die Grenzen der RecordBatches eines ungeordneten Ergebnisses folgen in 3.x den Stücken der Schreibpuffer (599/1/…). Sie hängen davon ab, wie geschrieben wurde; KuonenSQL teilt nach 600. Auch die Listen von SqlInfo 517 ordnet 3.x je Lauf anders; der Test ordnet sie. **Tests.** InfluxApiV3Tests.Text_gegen_Zahl_wie_das_Orakel, Flight-Tests (FV1–FV16, FX6 voll, FX13 wieder verglichen). Influx 178/178. Sabotage je rot: Systemschemas leer, IN ohne Typ, Textvergleiche aus. | ✅ |
IX37.14 3.x: Caches für letzte und eindeutige Werte |
Last Value Cache und Distinct Value Cache (`last_cache()`, `distinct_cache()` im SQL, angelegt über IX37.12), im Schreibpfad gefüllt ohne ihn zu bremsen, Ergebnis gleich wie aus der Tabelle; Grenzen (Anzahl Werte, Alter) wie gemessen. Die Python-Verarbeitung (Processing Engine) von 3.x bleibt aussen vor. Umgesetzt (Welle E): Last- und Distinct-Value-Cache, angelegt/gelöscht über `configure/last_cache|distinct_cache` (Vorgaben, Namen, 409/404/400 wie 3.x), gefüllt im Schreibweg aus dem, was nach dem Anlegen geschrieben wird (count, ttl, max_age, max_cardinality), gelesen über `last_cache()`/`distinct_cache()` im SQL und `system.last_caches|distinct_caches` (Spaltenkennungen in der Reihenfolge der Entstehung). Einstellungen in `influx.caches` der Datenbank. Gemessen sql-v3 C1–C23, gleich bis auf die inneren Kennungen/Zeiten der Anlege-Antwort. Rest IX37.14a. | ✅ |
IX37.14a 3.x: Inhalt der Caches nach Neustart |
Die Einstellungen der Caches überdauern einen Neustart, ihr Inhalt nicht (3.x füllt ihn aus dem WAL). Beim Start aus der Ablage füllen (je Schlüssel die letzten count Zeilen, je Kombination die jüngste Zeit). Die Antwort beim Anlegen nennt keine inneren Kennungen und Zeiten wie 3.x. Erledigt 2026-10-23: Nach einem Neustart füllt der erste Zugriff die Caches aus der Ablage (3.x aus seinem WAL): der Last-Value-Cache je Schlüssel mit den letzten count Zeilen, der Distinct-Value-Cache je Kombination mit der jüngsten Zeit (nur aus dem Zeitraum, den er zeigt). Die Antwort beim Anlegen nennt wie 3.x database_id, table_id, die Cache-Kennung und die Spalten als {"tag":i}/{"field":[0,i]}, dazu time_ns und sequence_number. sql-v3 C1, C3, C12 werden jetzt verglichen (Zeit und Folgenummer maskiert); Test Caches_nach_dem_Neustart_aus_der_Ablage. | ✅ |
IX37.15 Fehler, Grenzen und Kennung |
Statuscodes, Fehlertexte und JSON-Formen je Fassung wie das Orakel (Syntaxfehler mit Stelle in InfluxQL, `database not found`, `authorization failed`, `partial write`, `field type conflict`, `points beyond retention policy`, `max-series-per-database` usw.), Abbruch langer Abfragen (`query-timeout`, `KILL QUERY`), Schutz vor übergrossen Antworten (`max-row-limit`, Chunking). Ehrliche Kennung als KuonenSQL ausser in den Feldern, an denen Clients die Fassung erkennen. Umgesetzt (Welle H) für die Grenzen von 1.x, gemessen an influxdb:1.11 mit gesetzten Grenzen: `max-row-limit` (KUONENSQL_INFLUX_MAX_ROW_LIMIT; Zeilen über die ganze Antwort, gekürzte Serie `partial`, danach nichts mehr; chunked ohne Grenze), `query-timeout` (KUONENSQL_INFLUX_QUERY_TIMEOUT in s; `query-timeout limit exceeded`, folgende Anweisungen `not executed`, SHOW DATABASES ausgenommen), `max-series-per-database` (KUONENSQL_INFLUX_MAX_SERIES; neue Schlüssel je Punkt gezählt, Meldung wie 1.x; gilt für 1.x- und 2.x-Schreibwege). `max-values-per-tag` wirkt in 1.11 (TSI) nicht — gemessen, nichts zu tun. Alle voreingestellt aus wie 1.x. Fixtures grenzen-v1, serien-v1, zeitgrenze-v1 gleich. Fehlertexte, Statuscodes und Kennung je Fassung waren mit IX37.4–IX37.14 schon gemessen; KILL QUERY bricht eine laufende Abfrage noch nicht ab (Rest IX37.15a). | ✅ |
IX37.15a Abfragen wirklich abbrechen |
`KILL QUERY` nimmt eine Abfrage aus SHOW QUERIES, bricht ihre Ausführung aber nicht ab, und `query-timeout` prüft erst nach jeder Anweisung (IX37.15). Den Abbruch der laufenden Abfrage bis in den Ausführer und die Engine tragen (Abbruchmarke der Sitzung). Erledigt 2026-10-23: KILL QUERY und query-timeout brechen eine laufende Leseabfrage ab, nicht erst danach. Das Abbruchzeichen der laufenden Abfrage geht als `AbbruchToken` an die Engine (wie ein Attention über TDS) und an den InfluxQL-Ausführer (Prüfpunkte je Quelle, Gruppe und Zeile der Zusammenführung); die Zeitgrenze läuft über `CancelAfter`. Gemeldet wird wie am Orakel `query interrupted` (KILL) bzw. `query-timeout limit exceeded`, die folgenden Anweisungen `not executed`. Verwaltungsanweisungen führt 1.x ganz aus und meldet danach die Grenze (zeitgrenze-v1). Test `Kill_query_bricht_eine_laufende_Abfrage_ab` (Abfrage wartet auf die Sperre einer anderen Sitzung). | ✅ |
IX37.16 Treiber und Werkzeuge |
Abnahme gegen die echten Gegenstellen, je im Container oder Testprojekt: Telegraf (Ausgaben `influxdb` und `influxdb_v2`), Grafana (Datenquelle InfluxDB mit InfluxQL, Flux und SQL), `influx` 1.x und 2.x, `influxdb3`, Client-Bibliotheken (`influxdb-client-python`, `influxdb3-python`, `InfluxDB.Client` und `InfluxDB3.Client` für .NET, `@influxdata/influxdb-client` für Node, Java-Client), Node-RED und Home Assistant (Integration InfluxDB, beide Fassungen). Abgenommen (Welle H) gegen einen Server aus dem Zweig (2.x auf 18196, 3.x auf 18197) mit den echten Werkzeugen im Container: `influx` 2.7 (ping, org list, bucket create/list, write, query mit Flux, auth create/list, v1 dbrp list), `influx` 1.11 (SHOW DATABASES, SELECT über die Wege von 1.x am 2.x-Port), Telegraf 1.32 (Ausgaben influxdb und influxdb_v2, ohne Fehler; Daten über InfluxQL und Flux gelesen), `influxdb3` (show/create databases, write, query SQL, InfluxQL und JSON über Flight), Grafana 11.6 (InfluxQL schon IX37.2b; Flux: Health „6 buckets found“, Abfrage mit aggregateWindow; SQL über Flight SQL/gRPC: Health OK, Daten). Befunde behoben: `sa` fehlte als Benutzer von 2.x (`/api/v2/me`, influx auth create), `buckets()` in Flux fehlte (Health von Grafana). Rest IX37.16a. | ✅ |
IX37.16a Abnahme mit Client-Bibliotheken und Heimautomation |
Noch nicht gegen KuonenSQL abgenommen: influxdb-client-python, influxdb3-python, InfluxDB.Client und InfluxDB3.Client (.NET), @influxdata/influxdb-client (Node), Java-Client, Node-RED und Home Assistant (Integration InfluxDB, beide Fassungen). Braucht Pakete aus PyPI/NuGet/npm im Wegwerf-Container (Freigabe für den Download). Erledigt 2026-10-24: abgenommen gegen einen Server aus dem Zweig (2.x auf 18196, 3.x auf 18197), je Client im Wegwerf-Container. **Abgenommen.** - influxdb-client-python: ping, health, buckets, orgs, me, write (Punkt, Zeile, dict, Stapel), query (Tabellen, CSV, Strom, roh, extern-Parameter, DataFrame), delete, InfluxQL über /query. - influxdb3-python: write lp/Point/dict, SQL und InfluxQL über Flight, pandas, Parameter, Aggregate, reader, Schema, Fehler, SHOW TABLES. - InfluxDB.Client 4.18 samt Linq und InfluxDB3.Client 1.3 (.NET). - @influxdata/influxdb-client und @influxdata/influxdb3-client (Node 22). - influxdb-client-java 7.2 und influxdb3-java 1.2. - Node-RED mit node-red-contrib-influxdb (2.x mit Flux, 1.x über DBRP). - Home Assistant mit der Integration InfluxDB (api_version 2 und 1: Schreiben je Zustandswechsel, Sensor `influxdb` liest mit Flux bzw. InfluxQL zurück). **Befunde, behoben.** - 3.x über Flight: `iox::column::type` an jedem Feld (Tag, Zeit, Feldart), durch Alias, CAST, `::`, Vorzeichen, Unterabfrage, WITH, JOIN, UNION (letzter Teil mit Art) und first_value/last_value. InfluxDB3.Client und influxdb3-java lesen daraus in QueryPoints, was Tag und was Feld ist. - Bei InfluxQL am Schema die Gruppe (`tagKeyColumns`), die Messung und der Serienschlüssel. Am Schema des Plans (FlightInfo, vorbereitete Anweisung) bei SQL über einer Tabelle Messung und Serienschlüssel. - NULL-Fähigkeit wie 3.x: CAST einer Spalte, coalesce mit Literal, `time AS x`, information_schema und system, SHOW (ausser value), die Zeit bei einem einzelnen Selektor und GROUP BY time, count. - `first_value`/`last_value` als Aggregat (vorher „Invalid function“). - 2.x: `org` gilt als Kennung, wenn es sich als ID lesen lässt (Home Assistant schickt die ID). Eine unbekannte Org in /api/v2/query ist 400 invalid „failed to decode request body: …“. **Kein Befund.** - Java mit `params` (nur InfluxDB Cloud; 2.7 meldet dasselbe). - QueryPoints ohne Messung bei `SELECT *` (Orakel ebenso). - Gleichstand bei first() → IX37.16b. **Tests.** InfluxFlightTests (25 Fälle FM1–FM25, Fixture flight-v3 neu gemessen) und InfluxApiV2Tests (OI1–OI10, api2-v2 neu gemessen). Lauf Influx 176/176. Sabotage: Feldmetadaten aus, UNION-Regel vertauscht, first_value-Aggregat aus, Org-Kennung aus → je rot. | ✅ |
IX37.16b 3.x: Gleichstand bei first/last in InfluxQL |
Befund der Abnahme IX37.16a (gemessen an influxdb:3-core): bei gleicher Zeit wählt `first()`/`last()` in InfluxQL von 3.x den Punkt der ersten Serie (nach Serienschlüssel; `SELECT first(usage) FROM cpu` über a=0.25, b=2.5, c=11.5 zur selben Zeit → 0.25), 1.x und KuonenSQL den grösseren Wert (11.5, `FloatFirstReduce`). Braucht im gemeinsamen Ausführer von InfluxQL einen Schalter für 3.x (auch für min/max bei gleichem Wert prüfen). Erledigt 2026-10-24: gemessen in gleich-v3 (zwei Läufe an influxdb:3-core). **`first`.** Unter gleichen Zeiten nimmt 3.x immer die erste Serie nach Serienschlüssel, für Float, Integer, Text und Boolean (G1, G3, G5, G6). Am 3.x-Zugang gilt das jetzt auch für KuonenSQL; 1.x und 2.x behalten den grösseren Wert. **`last`.** 3.x wählt unter gleichen Zeiten je Lauf eine andere Serie (Lauf 1: 3.0, Lauf 2: 1.0; je Fenster ebenso). Das ist nicht festgelegt und wird nicht nachgebaut (G2, G9, G10 nicht verglichen). **Tests.** InfluxApiV3Tests.Gleiche_Zeiten_bei_first_wie_das_Orakel; Influx-Lauf 177/177. Sabotage (Schalter aus) → rot. | ✅ |
IX37.16c Sortierung: Erweiterungen wie ß = ss unter CI_AS |
Befund beim Messen für IX37.13a (am Orakel SQL Server 2025): unter Latin1_General_CI_AS gilt N'Straße' = N'STRASSE' (Erweiterung ß → ss), in KuonenSQL nicht (ON eines MERGE, WHERE, eindeutiger Schlüssel). Prüfen, welche Sortierungen Erweiterungen kennen (ß, æ, œ …), und die Vergleiche danach richten. Erledigt 2026-10-24: am Orakel SQL Server 2025 gemessen (17 Paare unter neun Sortierungen, dazu ORDER BY, GROUP BY, LIKE, CHARINDEX, PATINDEX, REPLACE und PRIMARY KEY). **Erweiterungen wie SQL Server.** - Unter den Windows-Sortierungen (nvarchar und varchar) gelten ß = ss, æ = ae, œ = oe, fi = fi, þ = th, ij = ij, dž = dž (je auch gross). - Unter SQL_Latin1_General_CP1_* gilt das nur für nvarchar; unter BIN/BIN2 nicht. - Nicht gleich sind ẞ = ß, ß = s, ä = ae (nur PhoneBook) und ʼn = 'n. - Gilt für Gleichheit, Ordnung, GROUP BY/DISTINCT, den Primärschlüssel und den Index. **LIKE, CHARINDEX, PATINDEX, REPLACE.** - Ein erweitertes Zeichen trifft nur ganz: `'Straße' LIKE '%ss%'` und `'Strasse' LIKE 'Straße'` treffen, `'Stras%'` und `'Stra__e'` nicht; `_` nimmt ß als ein Zeichen. - CHARINDEX(N'ss', N'Straße') = 5; REPLACE(N'Straße', N's', N'x') = N'xtraße'. **Tests.** ErweiterungenTests (3). Voller Lauf grün. Sabotage je rot: Erweiterungen aus, LIKE ohne Erweiterung. **Nicht nachgebaut:** German_PhoneBook (ä = ae). | ✅ |
IX37.17 Gleichwertigkeit und Abnahme |
Dieselben Messwerte über alle Zugänge (T-SQL, KSQL, PostgreSQL, MariaDB, MySQL, GraphQL) lesbar und bearbeitbar, `JOIN` von Zeitreihen mit Stammdaten; Sicherung und Wiederherstellung samt Aufbewahrungsrichtlinien und Continuous Queries; Prüfstand-Beispiele und Handbuchkapitel InfluxDB (M19), Zeitreihen im Objekt-Explorer des Studios; Leck-Lauf, Absturzprüfung über den Zugang; Schreibrate in M34, Dauerlast in M35. Erledigt 2026-10-23: dieselben Messwerte über T-SQL, KSQL, PostgreSQL, MariaDB, MySQL (echte Drahtprotokolle) und GraphQL lesbar und änderbar (`InfluxZugaengeTests`); JOIN mit Stammdaten ohne COLLATE (IX37.17b, Wahl B); BACKUP/RESTORE unter neuem Namen bringt Messungen, Aufbewahrungsrichtlinien und Continuous Queries zurück (`InfluxSicherungTests`, Gegenprobe ohne RESTORE rot). Handbuch, Objekt-Explorer, Lecklauf und Leistung → IX37.17c. | ✅ |
IX37.17c Influx: Handbuch, Studio, Dauerlauf |
Rest aus IX37.17: Handbuchkapitel InfluxDB-Zugang (Ports, Fassungen, Anmeldung, Grenzen), Influx-Datenbanken im Objekt-Explorer des Studios, Lecklauf und Absturzprobe unter Schreiblast, Leistungsvergleich nach M34/M35. Teil 2026-10-24 (Playground): Die Webseite kennt die Sprachen InfluxQL (8086), Flux (8086, 2.x) und Influx 3 SQL (8181), mit den üblichen Ports als Konstanten in InfluxEinstellungen. Inhalt: - Beispielkatalog mit 4 InfluxQL-, 2 Flux- und 2 SQL-Beispielen; der Wächter BeispielkatalogTests spielt sie über die echte HTTP-Schnittstelle gegen 1.x, 2.x und 3.x ab, mit dem Testclient InfluxClient. - Zugriffstabelle mit zwei Einträgen, Produktseite, Startseite. - Handbuchabschnitt je Sprache mit der Punktetabelle von M37. Sabotage ok (Schreiben im Client aus → 3 rot). Teil 2026-10-25 (Studio): Im Objekt-Explorer des MultiSQLManager stehen unter den Zugängen InfluxDB und InfluxDB 3 die Datenbanken mit Influx-Katalog, darunter Aufbewahrungsrichtlinien, Messungen, Tags und Felder (MSM `BaumInflux`, Orakeltest `ZugangssprachenTests.Der_Baum_zeigt_Datenbanken_Richtlinien_Messungen_Tags_und_Felder`); ihr Menü öffnet InfluxQL/Flux/SQL mit passender Abfrage, jeder Zugang lässt sich im Menü starten und beenden. Offen bleibt der Dauerlauf (Lecklauf, Absturzprobe, Leistung). | 🔶 |
IX37.17a MariaDB/MySQL: Schema und Tabelle in Backticks |
Befund aus `Influx/InfluxZugaengeTests` (23.10.2026): im MariaDB- und MySQL-Dialekt bricht `SELECT temp FROM `autogen`.`wetter`` mit „Unerwartetes Anweisungstoken '`'“ ab (Spalte des zweiten Bezeichners); ohne Backticks geht es. Am Orakel `mariadb` und `mysql` messen (zweiteilige Namen in Backticks, auch mit Leerzeichen) und im Lexer/Parser des Dialekts beheben; danach den Zugangstest auf Backticks umstellen. Erledigt (Welle G): kein Fehler im Zugang. Der Zugangstest rief die Engine direkt mit gesetztem Dialekt auf — die Übersetzung von MariaDB/MySQL (und PostgreSQL) geschieht aber im Anschluss, nicht in der Sitzung. InfluxZugaengeTests sprechen jetzt MariaDB, MySQL und PostgreSQL über ihre Leitungsprotokolle (MariaTestclient, PgTestclient), mit `` `autogen`.`wetter` `` bzw. `"autogen"."wetter"`: 25/25 grün. | ✅ |
IX37.17b Befund: JOIN von Tags mit Stammdaten braucht COLLATE |
Tags und Textfelder liegen binär sortiert (Latin1_General_BIN2, wie InfluxDB unterscheidet Gross/Klein). Ein JOIN mit einer Textspalte in der Sortierung der Datenbank gibt wie in SQL Server Fehler 468 (Sortierungskonflikt); mit `COLLATE DATABASE_DEFAULT` geht er (InfluxZugaengeTests.GraphQL_und_JOIN_mit_Stammdaten). Entscheid Marc: so lassen (influxtreu) oder Tags in der Sortierung der Datenbank ablegen. Entscheid Marc 23.10.2026: Tags und Textfelder in der Sortierung der Datenbank. Neue Spalten entstehen ohne COLLATE; `_serie` und der Katalog bleiben binär (Sion und sion sind zwei Serien), InfluxQL/Flux/3.x vergleichen selbst binär, das Löschen über 2.x mit Prädikat vergleicht ausdrücklich binär. JOIN mit Stammdaten ohne COLLATE (InfluxAblageTests, InfluxZugaengeTests). Bestehende Tabellen behalten ihre binären Spalten. Sabotage: Tag-Spalten binär → 3 Tests rot. | ✅ |
In InfluxDB 3 ist jede Messung eine Tabelle mit den Tags, den Feldern und time; abgefragt wird mit SQL.
USE pruefstand INSERT sql_wetter,ort=Bern temperatur=12.5 1735689600000000000 INSERT sql_wetter,ort=Zuerich temperatur=10 1735689600000000000 SELECT ort, temperatur, time FROM sql_wetter ORDER BY ort
ort | temperatur | time Bern | 12.5 | 2025-01-01T00:00:00 Zuerich | 10.0 | 2025-01-01T00:00:00
date_bin teilt die Zeit in gleich lange Fenster; GROUP BY rechnet je Fenster und Ort.
USE pruefstand INSERT sql_mittel,ort=Bern temperatur=10 1735689600000000000 INSERT sql_mittel,ort=Bern temperatur=12 1735691400000000000 INSERT sql_mittel,ort=Bern temperatur=14 1735693200000000000 SELECT date_bin(INTERVAL '1 hour', time) AS stunde, ort, AVG(temperatur) AS mittel FROM sql_mittel GROUP BY 1, ort ORDER BY 1
stunde | ort | mittel 2025-01-01T00:00:00 | Bern | 11.0 2025-01-01T01:00:00 | Bern | 14.0
