Eine neue Version der sQLshell ist verfügbar!

Die sQLshell bietet nun die Möglichkeit, durch den Anwender neue Datenbankmanagementsysteme zu unterstützen, ohne die Anwendung ändern zu müssen.

Die sQLshell prüft nun beim Import die Signatur und das Zertifikat des Signierenden, falls die XML-Datei bzw. das zugehörige Schema eine XML-Signatur aufweist.

Die Idee, den Nutzer zu ermächtigen, selbst weitere Datenbankmanagementsysteme zur Liste der bereits unterstützten hinzuzufügen kam ich, als ich auf arxiv im Bereich Datenbanken über einen Artikel zu einem SLQ-Debugger stolperte.

Neugierig geworden las ich mir zunächst den Artikel durch und recherchierte anschließend die darin genannte Softwarelösung namens Calcite - ein Apache-Projekt. Ich arbeitete das Tutorial durch und stellte fest, dass es - zumindest aus meiner Sicht - etwas Ähnliches wie das bereits durch die sQLshell unterstützte Apache Drill darstellt. Das fand ich zwar interessant, nicht jedoch so sehr, als dass ich deshalb die Sourcecode-Basis der sQLshell unbedingt größeren Änderungen hätte unterziehen wollen. Also kam mir der Gedanke, dass es doch mit minimalen Änderungen am bestehenden Code, der es ermöglicht, andere JDBC-Treiber für die unterstützten Datenbankmanagementsysteme zu verwenden, auch möglich sein müsste, als Anwender gänzlich neue Datenbankmanagementsysteme zur Liste der unterstützten hinzuzufügen.

Ich musste dann doch eine ganz kleine Code-Änderung durchführen - der Inhalt der Datei _JarLocation.template wurde bisher als Name einer JAR-Datei interpretiert. Meine Tests mit Calcite ergaben eine erstaunliche Anzahl von 46(!) benötigten JARs - nur um die absolute Basisfunktionalität nutzen zu können. Ein solches Beispiel für Dependency-Hell muss klar vom Rest der Anwendung und auch vom Rest des Systems isoliert werden - also wird der Inhalt des Dateipfades in _JarLocation.template jetzt ald Name eines Verzeichnisses interpretiert, falls er mit dem Zeichen endet, das auf dem benutzten Betriebssystem als Trenner von Bestandteilen eines Verzeichnispfades benutzt wird. In diesem Fall werden alle darin enthaltenen JARs zum Klassenpfad hinzugefügt. Der Inhalt der drei Dateien, um Calcite als unterstütztes Datenbankmanagementsystem zur sQLshell hinzuzufügen:

123_DriverClassName.template

org.apache.calcite.jdbc.Driver

123_JarLocation.template

/Calcite/lib/

123_URL.template

jdbc:calcite:model=${db}

Der Test geschah mittels der JDBC-Bridge von Calcite - das model dafür sah wie folgt aus:

{
  version: '1.0',
  defaultSchema: 'PSchema',
  schemas: [
    {
      name: 'PSchema',
      type: 'custom',
      factory: 'org.apache.calcite.adapter.jdbc.JdbcSchema$Factory',
      operand: {
        jdbcDriver: 'org.postgresql.Driver',
        jdbcUrl: 'jdbc:postgresql://postgresqlserver.docker.lab:5432/jdbctest',
        jdbcUser: '*****',
        jdbcPassword: '*****'
      }
    }
  ]
}

Wichtig wäre hierbei noch zu erwähnen, dass ich damit zwar die Verbindung herstellen konnte, allerdings war danach die Ausführung beliebiger SQL-Statements nicht möglich - die Fehlermeldungen glichen sich immer: Ein Identifier - alles in Großbuchstaben - konnte nicht gefunden werden, ob ich (hier die korrekte Schreibweise wie sie in der Datenbank und auch im Statement benutzt wurde) gemeint hätte? Dieses Problem ließ sich über einen der Properties für den Aufbau der Verbindung - caseSensitive - beheben.