Die sQLshell hat eine weitere Integration erfahren - obwohl ich eigentlich selber nicht viel dazu tun musste: Es existiert ein Projekt/Produkt namens steampipe, dessen Slogan ist select * from cloud; - Im Prinzip eine Wrapperschicht um diverse (laut Eigenwerbung mehr als 140) (cloud) data sources.

Nachdem ich mich ein wenig eingelesen hatte, dachte ich zwangsläufig: SQL - das bringt mich auf JDBC und das wiederum lässt mich sofort an die sQLshell denken. Durch die letzten größeren Brückenschläge ermutigt begann ich, darüber nachzudenken, ob ich dieses Projekt in der sQLshell würde nutzen können.

Die Beschreibung erläutert zunächst nur, wie eine Integration in PostgreSQL oder SQLite vor sich geht. Die Erklärungen bleiben aber da stehen, wo die Interaktion entweder mit der steampipe-CLI oder mit den jeweiligen proprietären Datenbank-Frontends erläutert werden.

Daher musste ich mich zunächst nun für eine der beiden Möglichkeiten entscheiden. Da ich meine letztenm Erfolge mit PostgreSQL gefeiert hatte und die Daten ja sowieso nicht in der eigentlichen Datenbank, sondern in der Cloud liegen würden und die Datenbank dafür nur eine Fassade wäre entschied ich mich für SQLite: Man braucht keinen Server und kann die Datenbank sogar in-memory implementieren. Das wäre eine wirklich schlanke Fassade für riesigen Cloud-Datenquellen.

Dafür musste ich jedoch von der Anleitung ein wenig abweichen: Die eigentliche Extension installierte ich noch so wie angegeben, aber da ich nicht das proprietäre Frontend benutzen wollte, wich das restliche Vorgehen ein wenig ab:

Die Extension lud ich mittels

SELECT load_extension('/path/to/steampipe_sqlite_github','sqlite3_extension_init');

Wichtig war hier das Weglassen der Endung der Extension.

Über die JDBC Connection Properties sollte unbedingt auch noch enable_load_extension auf den Wert true gesetzt werden.

Anschließend konnte ich das von mir auserkorene Beispiel Github mittels

select steampipe_configure_github('token="xxx_xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx"');

erfolgreich konfigurieren und anschließend erste Abfragen absetzen. Sieht man dabei Fehlermeldungen, in denen etwas Ähnliches wie code = Internal desc = 'List' call requires an '=' qual for column: repository_full_name auftaucht, zeigt das an, dass die betreffende Pseudotabelle zwingend eine WHERE Klausel erwartet.

Das erste erfolgreiche Statement, das ich also absetzen konnte, lautete:

select * from github_pull_request where repository_full_name='elbosso/rfc3161timestampingserver';

Der einzige Wermutstropfen hierbei ist, dass ich in der sQLshell keine Angaben über die verfügbaren Tabellen bekomme, während das mit dem proprietären Frontend der SQLite Datenbank durchaus möglich ist.

Aber: die diversen Komfortfeatures wie etwa das Reporting in der sQLshell sind damit auch auf irgendwelche Datenquellen in der Cloud anwendbar!

Artikel, die hierher verlinken

Kommentar hinzufügen (via ) Kommentare ansehen (via )

Kommentar hinzufügen (via ) Kommentare ansehen (via )