JSqlParser: SQL als bearbeitbaren Java-Syntaxbaum nutzen

Vom Text zum Baum

Das README zeigt `select 1 from dual where a=b` als `PlainSelect`. Select-Items, Tabelle, Bedingung und Spalten sind getrennte Knoten. Ein Visitor kann diesen Baum durchlaufen; derselbe Objektansatz dient auch dazu, Statements ueber eine Fluent API aufzubauen und wieder als SQL auszugeben. Damit ist JSqlParser mehr als ein Regex-basierter Filter.

Abhaengigkeit und Version

Die Anleitung unterscheidet stabile Upstream-Koordinaten von den kontinuierlich gebauten Manticore-Artefakten. Genannt werden `com.manticore-projects.jsqlformatter:jsqlparser:[5.3.218,)` und upstream `com.github.jsqlparser:jsqlparser:5.3`. Diese Wahl beeinflusst Grammatik, API und Performance. Ein Build sollte daher nicht unbesehen ein dynamisches `+` aus dem Gradle-Beispiel uebernehmen.

AST-Zugriff

Im Beispiel wird `CCJSqlParserUtil.parse` auf `PlainSelect` gecastet, danach werden `getSelectItems()`, `getFromItem()` und `getWhere()` verwendet. `EqualsTo` liefert linke und rechte Expression; `Column` stellt den Spaltennamen bereit. Diese konkreten Typen sind gute Integrationspunkte fuer Linter, Maskierung oder SQL-Transformationen. Jeder Cast ist zugleich eine Annahme ueber die Eingabesyntax.

Dialekte und Grammatik

JSqlParser positioniert sich als RDBMS-agnostischer Parser mit einer Grammatik fuer mehrere Dialekte. Die README verweist auf Syntax, Samples und Changelog. RDBMS-agnostisch bedeutet hier nicht, dass jedes proprietaere Feature gleich behandelt wird. In einer Anwendung sollten Dialektwahl, Kommentare, Quotes, CTEs und Erweiterungen des Zielsystems als eigene Testfaelle gefuehrt werden.

Leistung richtig lesen

Die README nennt selbst berichtete Vergleiche wie 11-fach gegen Version 5.3 und 19-fach gegen `sqlglot[c]` auf der eigenen SELECT-Suite. Das sind Projektdaten, keine universelle Garantie. Parser-Leistung haengt an Statementlaenge, Dialekt, Speicher und daran, ob nach dem Parsen noch Visitor- oder Render-Schritte folgen. Die eigene Query-Sammlung ist deshalb aussagekraeftiger als die plakative Zahl.

Pruefung im Projekt

Baue einen kleinen JVM-Test mit `CCJSqlParserUtil.parse` fuer SELECT, UPDATE und eine absichtlich nicht unterstuetzte proprietaere Klausel. Vergleiche die erwarteten Knoten von `PlainSelect`, `Table` und `EqualsTo`; rendere eine veraenderte Bedingung wieder zu SQL. Fixiere dabei eine konkrete Maven-Version und protokolliere Parse-Fehler sowie Laufzeit. So wird die Dialektgrenze sichtbar.

Zwischen Analyse und Ausgabe

Der praktische Wert von JSqlParser liegt in der bidirektionalen Strecke. Nach `CCJSqlParserUtil.parse` kann ein Visitor die Knoten untersuchen oder veraendern; anschliessend muss die gerenderte SQL-Ausgabe semantisch zum Ausgangsstatement passen. Das ist bei Tabellen- und Spaltennamen mit Quotes, Unterabfragen und Dialektbesonderheiten anspruchsvoller als das einfache `dual`-Beispiel. Die im README genannte Fluent API ist daher besonders interessant fuer Generatoren, aber auch dort sollte ein Test die erzeugte Zeichenfolge gegen die Ziel-Datenbank pruefen. Die Manticore-Version und die upstream-Version sind getrennte Bezugsquellen, nicht bloss zwei Schreibweisen. Wer die aktuelle Entwicklungszeile nutzt, muss Release- und Changelog-Aenderungen in die Build-Entscheidung einbeziehen.

Ein belastbarer Integrationsfall

Ein sinnvoller Test beginnt mit dem README-Statement `SELECT 1 FROM dual WHERE a = b`, bleibt aber dort nicht stehen. Fuege Tabellenalias, verschachtelte Abfrage, mehrere SelectItems und eine fuer das Zielsystem typische Quote hinzu. Nach `CCJSqlParserUtil.parse` sollten Visitor-Pruefungen den erwarteten `Table`- und `Column`-Namen lesen, ohne nur auf die Textdarstellung zu vertrauen. Wird eine Bedingung veraendert, muss der Renderer ein gueltiges Statement erzeugen. Ein zweiter Test nutzt die Fluent API und vergleicht die Ausgabe mit einer Datenbankparser-Pruefung. Dabei werden auch Kommentare, Gross-/Kleinschreibung und Parameterplatzhalter relevant. Die Maven-Koordinate muss im Testprojekt festgeschrieben sein; ein dynamisches Gradle-`+` macht einen spaeteren Fehler schwer nachvollziehbar. Die README nennt Samples, Syntax und Changelog als naechste Anlaufstellen. Diese Dokumente sollten fuer genau die Dialekte gelesen werden, die der Dienst verarbeitet. Die Java-Typen im AST sind eine oeffentliche Arbeitsoberflaeche, aber jeder Cast bindet den Aufrufer an die erwartete SQL-Form. Ein Visitor sollte unerwartete Statementtypen kontrolliert behandeln und Parse-Fehler mit dem Originaltext protokollieren. So bleibt nachvollziehbar, ob eine Aenderung aus JSqlParser, aus dem Dialekt oder aus der eigenen Umschreibung stammt. Fuer Batch-Verarbeitung sind ausserdem Speichergrenzen und die Behandlung mehrerer Statements zu messen. Ein erfolgreicher Parse allein sagt nichts ueber die Sicherheit einer spaeteren Ausfuehrung aus. Die Bibliothek liefert einen Baum; Autorisierung und Parameterbindung bleiben Aufgaben der Anwendung. Wiederholbare Tests mit echten Abfragen schaffen hier die notwendige Trennlinie zwischen Parserfunktion und Datenbankverhalten.

Redaktionelles Fazit

Geeignet ist JSqlParser fuer ein Team, das SQL analysiert, umschreibt oder aus Java heraus erzeugt und die im README genannten Schnittstellen selbst prueft. Ungeeignet ist das Projekt fuer die Erwartung, dass eine allgemeine Demo bereits die eigene Produktionsumgebung abdeckt. Vor der Entscheidung sollte `CCJSqlParserUtil.parse(sqlStr)` mit den eigenen Dialekten mit einer kleinen, realen Eingabe ausgefuehrt werden. Beobachtet werden sollten konkrete Ausgaben, Fehlermeldungen und der Aufwand fuer Versionswechsel, nicht nur ein erfolgreicher Erstlauf.

Offizielle Quellen

1. Official documentation
2. Official README
3. Project repository
4. Release notes