PostgreSQL-Parser in Java (Alternative für ANTLRv4 und GSP)

Java-Forum APIs & Frameworks
1

Hi Community,

Ich habe ein Frage bezüglich Java. Wie man vielleicht aus der Überschrift auslesen kann, suche ich eine Möglichkeit um Postgres-Skripte in Java zu parsen und möglichst gleich zu zerlegen.
Mein Ziel ist es hauptsächlich, eine bestehnde DB-Logik durch Auslesen und Umwandeln in Java auszulagern. Dazu habe ich bereits 2 Bibliotheken getestet:

  • ANTLRv4 mit folgender Postgres-Grammatik
    [ul]
    [li]zerlegt Statements anhand der Grammatikregeln in Tokens, die dann traversiert werden können
    [/li][li]einzelne Wörter und Phrasen müssen gegebenenfalls manuell per String-Analyse entnommen werden
    [/li][/ul]

  • JSqlparser (Source)
    [ul]
    [li]zerlegt SQL-Statements in JSon-ähnliche Objektstrukturen
    [/li][li]einzelne Wörter und Attribute des Statements kann man dann ganz normal über die Map abgreifen
    [/li][li]leider nicht direkt für PostgreSql ausgelegt
    [/li][li]Funktionsweise ähnlich GS (General SQL Parser)
    [/li][/ul]

Soweit so gut mein Stand. Leider aber haben beide Bibliotheken das gleiche Problem:
Sie verarbeiten keine Prozeduren/Funktionen in SQL. Das ist natürlich großer Mist für mich, da dort der Löwenanteil aller Logik enthalten ist.
ANTLR erkennt zwar die Funktionen an sich, aber nimmt sie als kompletten String, den er dann als eben Riesenobjekt auch so weitergibt.
JSqlparser erkennt die Funktion (je nach Komplexität und Aufbau) auch, stopft diese dann aber genauso in ein einziges Objekt.
Immerhin kann man aber bei beiden zumindest noch Rückgabewert und Übergabeparameter auslesen :rolleyes:

Ich habe nach sehr ausgiebiger Recherche als einzige vermeintliche Alternative GSP gefunden gefunden. Leider kostet dieses Programm eine Stange Geld und das habe ich/lohnt sich nicht.
Deswegen bin ich aktuell auf der Suche nach einer kostenlosen/günstigen Alternative, die ich einsetzen könnte? Also wäre echt klasse, wen mir da jemand vielleicht einen Tipp geben könnte.
Da ich mal davon ausgehe, dass 80% der Entwickler hier mehr Erfahrung als ich im Bereich Java haben, bin ich (noch) guter Dinge :stuck_out_tongue_winking_eye:

Grüße und schon einmal vorab vielen Dank!

2

java - Are there any alternatives to GSP (General SQL Parser)? - Stack Overflow

gewiss gesehen, von 2011, sieht ja nicht nach Alternativen aus,
wie hoch wären denn die Kosten für GSP als Info?

was machst du eigentlich mit den geparsten Daten, jeden Befehl in eine andere DB-Sprache oder eben Java übersetzen?
spätestens da wirst du doch nichts fertiges mehr finden, und sowieso jeden Punkt einzeln behandeln müssen,
vielleicht auch in größeren Gruppen die geparst nicht gut zu erfassen sind?

wäre nicht ein simples Eigenparsen mit Zerlegen in Token nur getrennt durch Leerzeichen, Klammern usw. schon ausreichender Start?
gilt aber fast für jeden Parser, ich bin da wohl unflexibel eingestellt :wink:

bei dir würden vorerst wohl mehrere Sprachen wegfallen, ein gutes Argument für die professionelle API (manuell Mehrfacharbeit)

Vorteil bei eigenen Code könnte sein, ziemlich jede Besonderheit auch zu erwischen,
notfalls mit Fehlermeldung falls mal was neues kommt, was der eigene Parser noch nicht versteht,

besteht bei fertig analysieren Objekten nicht dagegen die Gefahr, dass irgendein exotischer Bestandteil wie try-catch/ Annotation übersprungen wird,
weil als optionales Unterobjekt konfiguriert? nur zu finden wenn aktiv nachgefragt, was unterlassen?

3

Ja, angesichts der (schockierend) geringen Beiträge in dem Bereich und der Tatsache, dass **wenn **sich mal jemand mit „DB-Query to Highlanguage“ beschäftigt, man entweder nur pure SQL oder PL/Oracle in den Fokus nimmt…
War es relativ schwer einen Beitrag **nicht **zu finden. Ich habe sogar einen kurzen Vergleich aller (vermeintlichen) Alternativen gefunden:

What is the best SQL parser in Java?

Allerdings ist der gute Mensch da stehengeblieben, wo ich weitergemacht habe. Wie erwähnt habe ich ANTLR ja zu genüge getestet :wink:
Nichtsdestotrotz ist der Beitrag von 2012 gewesen, und ich kann mir gerade in der Informatik nicht vorstellen, dass es seitdem Null Weiterentwicklung gegeben haben soll ^^’

Und wegen dem Preis…weit über dem, was ich für meine Abschlussarbeit bereit bin auszugeben. Aber schau selbst:

[SPOILER][ul]
[li]
[/li][/ul][/SPOILER]

Gut, da das wohl relevant ist um meine Motivation zu verstehen - hier ein kurzer Abriss :stuck_out_tongue_winking_eye:
Ich schreibe meine BA bei einer externen Firma, die mich dafür auch (theoretisch) gut entlohnt. Deren Problem ist, dass sie sich vor Jahren mal eine Anwendung zur Datenerfassung gekauft haben, allerdings kein Schwein mehr weiß was in dem Ding eigentlich abgeht und daher Wartung/Anpassung schwer bis unmöglich ist. So, hier kommt also der Student für die Drecksarbeit ins Spiel :kiss:

Kurz: Analyse der DB, inklusive deren Verhalten plus Übersetzung in Java um eventuelle Migration später zu erleichtern.

Ein Punkt ist bei dir also bisschen falsch rübergekommen:
Hier geht es eigentlich nur um PostgreSQL, zumindest vorerst. Allerdings ist da eben auch der Knackpunkt, weshalb ich nicht einfach nen Riesenstring mit Separatoren nehmen kann.
Ziel des Ganzen ist die DB möglichst auf das zu beschränken, wofür sie gedacht ist - sprich Daten lesen, schreiben und gegebenenfalls aktualisieren. Alles andere soll halt in Java erfolgen.
Um es dir etwas besser zu veranschaulichen ein kurzes Beispiel:

Statt jetzt einer ellenlangen Prozedur mit x-fach geschachtelten SELECT-Befehlen, die am besten noch mehrfach Bedingungen abgleichen müssen, soll das einfach in Java über einfache SELECT- und DROP-Befehle erfolgen.
Sprich Bedingungen, Prüfungen und Schachtelungen sollen vorher abgewickelt werden.
Etwas deutlicher - ein IF in SQL wird zu if-else in Java bzw. ein Loop per for/while/do-while abgehandelt.

Und ja, den Teil muss ich dann so oder so selbst erledigen.
Aber bevor ich mir die Mühe mache, mich mit der Grammatik von Postgres zu schlagen und da ewig debugge bis alles reibunglos erkannt wird - Ich denke du verstehst mich :wink:
Der zweite Teil wird auch so schon groß genug werden und mit 3-4 Monaten hast da keine Chance.

Und nein, das sollte nicht passieren.
Es handelt sich prinzipiell um eine theoretische Betrachtung, die aber natürlich irgendwo auch praktisch von mir belegt werden soll… Wobei, du kannst dir sicher denken, dass die Firma schon gern einen Erfolg als Ergebnis sehen würde.
Jedenfalls ist mein Ansatz momentan, das Ganze über Komposite-Pattern zu lösen. Sprich Statements werden durch geschachtelte Objekte ähnlich JSon repräsentiert und im Nachgang dadurch abgehandelt.

PS: Interessant, wenn man im Nachgang festellt, wie viel Fehler man trotz 4 mal Korrekturlesen noch drin hatte in seinem Beitrag.

PSS: Danke für die schnelle Reaktion :daumen:

4

Hallo Community,
Gibt es denn echt Keinen, der mir helfen kann in dem Bereich? :frowning:

Grüße

5

Was du vorhast macht man sehr selten, weil:

… der generierte Java Code alles andere als „richtiger“ Java Code waere, und damit eben nicht die Vorteile bietet die man von „richtigem“ java Code erwartet.

„richtig“ heisst in diesem Fall nicht nur dass er kompiliert und das richtige Ergebniss liefet, sondern auch dass die Struktur wie Java Code aussieht und sich eben leichter warten laesst.

Ich will deine Traeume/Plaene nicht schlecht machen, aber die Idee an sich ist IMHO kaputt, sowas generiert man nicht, sowas schreibt man mit der Hand.

6

mit genügend, evtl. mehr Zeit = Geld und Expertem/n sowohl in den Postgres-Skripten
(nicht nur Syntax an sich, sondern auch den Sinn hinter großen Konstrukten sehen)
als auch dann Java kann man sich Handarbeit vorstellen,

hätte aber in jedem Fall eine komplett neue Anwendung,
die in jeder einzelnen Zeile beliebige Fehler haben kann, normale unbewußte oder bewußt nach Falschinterpretation des Originals

dem gegenüber hat eine automatische Migration nach überschauberen Regeln (sofern möglich) eigene Vorteile:

ob in Java alles genauso abläuft (Daten aus DB geholt? Sortierung, Datentypen, Formatierungen, …) wäre zu zeigen,
aber wenn für einen etwas genauer untersuchten kleinen Teil der Skripte perfekt laufend und danach auf Gesamtmenge ausgeführt in Vergleichstest korrekt,
dann schon ziemlich überzeugend (würde man für die Hand-Java-Version natürlich auch machen),
auch wenn sich natürlich immer Risiken für spätere Sonderfälle verstecken können (in beiden),

zu lesen wäre der Java-Code dann wahrscheinlich nicht, die Skripte weiterhin die Referenz,
aber der Java-Code dazu ohne DB (insbesondere speziell Postgres) lauffähig,
eine durchaus interessante Alternative

und vor allem dann ein fertiges Tool für evtl. andere Skripte auch, während Hand-Java-Version wieder komplett neu zu programmieren wäre,
die Größe des aktuellen/ zukünftigen Einsatzgebietes bestimmt die Kostenfrage,

zudem Änderungen in den Skripten möglich + neue Java-Version, falls sich dazu weiterhin jemand besser auskennt als in Java etwas anzufassen,
geht ja Richtung Emulator – Wikipedia :wink:

7

Hallo und danke erst einmal für die erneut schnellen Antworten.
Es tut mir Leid, dass ich mich erst jetzt zurückmelden kann, ich hatte durch das Projekt Einiges um die Ohren.

[QUOTE=maki][…]der generierte Java Code alles andere als „richtiger“ Java Code waere, und damit eben nicht die Vorteile bietet die man von „richtigem“ java Code erwartet.
[…]die Struktur wie Java Code aussieht und sich eben leichter warten laesst.
[…]sowas generiert man nicht, sowas schreibt man mit der Hand.[/QUOTE]

Mir steht eine externe Bibliothek zum Generieren von Java-konformen Klassen bereit, welches nicht nur funktionierenden sondern auch korrekt formatierten Code erstellt. Das Tool wurde hinreichend in anderen Projekten genutzt und
ausgiebig getestet - sollte also für meine Ansprüche mehr als ausreichend sein.
Es geht ja bei dem Projekt um ein Konzept zur Automatisierung, heißt es gibt keinen Anspruch auf Fehlerlosigkeit. Ich soll lediglich einen Vorschlag erarbeiten, wie man es machen könnte. Ob das sinnvoll bzw. dann tatsächlich genutzt wird oder nicht, ist dann eine andere Geschichte. Drum herum, einen funktionierenden Prototypen zu erstellen komme ich aber so oder so nicht.
Würde ich aber einfach nur per Hand die Logik in Java umsetzen, wäre die Abhandlung in der Arbeit ja nicht nötig.
Ich hoffe du verstehst, was ich meine :slight_smile:

edit SlaterB:
es gab hier zwei freizuschaltene Postings, beide freigeschaltet, ersten wiederherstellbar gelöscht,

mit Nachfolgeposting und Zusammenfassung ging zweiter Beitrag wieder zur Freischaltung, dabei diesmal nun von mir ganz gelöscht, nicht gut,
für mich nicht so leicht wiederherzustellen,

deswegen nun das erste der beiden Postings zumindest wieder ent-löscht…,
eine zweite Hälfte mit Bezug auf meine Postings fehlt, grober Inhalt: Lob :wink: , Verteidigung Lesbarkeit, Bezug auf Emulator nicht recht verstanden

8

na, ob man Programm X in abweichender Umgebung Y als Quellcode interpretiert (Emulator)
oder X automatisch übersetzt so dass es in Y normal läuft,
wird den Anwender im Detail nicht unbedingt interessieren, beides bringt Laufen in Y :wink:

zur Lesbarkeit:
dass normaler Java-Code mit normalen Methoden, Variablen, Schleifen rauskommt ist durchaus schon vorausgesetzt, jede Zeile einzeln lesbar,

aber der automatisch generierte Code wird sicher nicht ideale Benennungen vornehmen, Kommentare an Methoden schon gar nicht,
keine Optimierungen wie gleiche Bestandteile in Untermethoden extrahieren und wer weiß was alles,

mit (guten) handgeschriebenen Code nicht wirklich vergleichbar, die Lesbarkeit im Großen (Klassen, hunderte Zeilen) leidet

9

[QUOTE=SlaterB][…]nicht ideale Benennungen vornehmen, Kommentare an Methoden schon gar nicht,
keine Optimierungen wie gleiche Bestandteile in Untermethoden extrahieren und wer weiß was alles[…]
[/QUOTE]
Naja, aus meiner Erfahrung heraus würde ich sagen, dass das auch bei vielen/sehr vielen handgeschriebenen Programmen (im semi-professionellen Bereich) zutrifft :stuck_out_tongue_winking_eye:
Ansonsten hast du wohl Recht, dass man über gewisse Hindernisse nicht drüber kommen wird. Besser als das vorhandene DB-Chaos wäre es aber dennoch allemal (theoretisch).