.NET

Legacy-Funktionen & Historie

OmniDB hat mehrere sehr unterschiedliche Leben durchlebt — ein Universitätsprojekt, eine Python/Django-Webanwendung mit einem Plugin-Ökosystem, und nun eine Go-Anwendung als Einzel-Binärdatei. Diese Seite ist der Ort für alles, was es einmal gab, aber heute nicht mehr gibt: was es war, warum es nicht zurückkehrt, und wo Sie es finden, falls Sie es noch benötigen. Für die Geschichte des Projekts selbst siehe Einführung.

Versionshistorie

Ära Was es war
Original (ASP. NET/C#) Abschlussprojekt im Grundstudium an der Bundesuniversität von Paraná — das erste Werkzeug, das eine gemeinsame Linie zwischen den Metadaten von PostgreSQL, MySQL/MariaDB, Oracle, SQLite, Firebird und SQL Server zog.
OmniDB (Python/Django) Die langlebige Version, die die meisten kennen: eine Django-Webanwendung mit browserbasiertem Arbeitsbereich und, ab Version 2.9, einem Python-Plugin-System für Community-Erweiterungen. Die Entwicklung im ursprünglichen Repository OmniDB/OmniDB wurde um 2020 eingestellt.
Wiederbelebung 2025–2026 (3.1.x) Das Projekt wurde wieder aufgenommen: modernisierte Codebasis, verbesserte Sicherheit, native Unterstützung für macOS Apple Silicon und eine vollständige Überarbeitung der Dokumentation — zu diesem Zeitpunkt noch auf dem Python/Django-Backend.
Go-Neufassung (3.6.x) Das gesamte Backend wurde von Python/Django auf Go umgeschrieben und als einzelne native Binärdatei ausgeliefert. Die Python-Laufzeitumgebung und alles, was nur innerhalb von ihr Sinn ergab — einschließlich des Plugin-Systems — wurde entfernt.
Wails-Migration (abgeschlossen) Die Desktop-Shell wechselte von NW.js zu Wails (Go) — eine kleinere Binärdatei, kein gebündeltes Chromium, und die Anwendung nutzt nun stattdessen die native Webview des Betriebssystems.

Das Plugin-System (entfernt)

Das Plugin-System wurde im Zuge der Neufassung des Backends von Python/Django auf Go in 3.6.x entfernt und ist nicht mehr verfügbar.

OmniDB 2.9 führte ein Plugin-System ein, mit dem Benutzer Python-Code schreiben konnten, der in verschiedene Teile der Oberfläche eingehängt wurde, um eigene Funktionen hinzuzufügen, ohne die gesamte Anwendung neu auszurollen. Dieser Mechanismus beruhte darauf, beliebige Python-Module dynamisch in den laufenden Serverprozess zu importieren — etwas, das in einer kompilierten Go-Binärdatei keine Entsprechung hat — und wurde bewusst nicht übernommen. Da er ohnehin nie wieder etwas Sinnvolles hätte tun können, wurden der „Plugins“-Dialog samt seinem Menüeintrag sowie die dahinterliegenden API-Endpunkte vollständig aus der Anwendung entfernt, statt als dauerhaft leerer Platzhalter erhalten zu bleiben.

Wenn Sie auf ein bestimmtes Plugin angewiesen waren, gibt es derzeit keinen unterstützten Weg, es zu portieren. Alles, was ein Plugin früher durch direkten Zugriff auf die Datenbank erledigte, lässt sich in der Regel auch heute noch über den regulären SQL-Editor, Snippets oder eine eigene Monitoring-Einheit erledigen.

PL/pgSQL-Schrittdebugger (entfernt)

OmniDB 2.3.0 fügte einen interaktiven Schrittdebugger für PL/pgSQL-Funktionen und -Prozeduren hinzu — Breakpoints, Live-Variableninspektion und zeilenweise Ausführungsstatistiken. Er beruhte auf einer eigenen PostgreSQL-C-Erweiterung (omnidb_plugin), die sich in die interne Plugin-API von PL/pgSQL einhängte, geladen über shared_preload_libraries (was einen Serverneustart erforderte), sowie einem eigenen omnidb-Schema und passwortlosem lokalem Zugriff für eine zweite, nur für den Debugger bestimmte Datenbankverbindung.

Der Debugger wurde entfernt, ebenso seine Baummenüeinträge „Debug Function“/„Debug Procedure“. Er wurde während der Go-Neufassung in 3.6.x nie portiert, und die Erweiterung omnidb_plugin selbst wurde seit 2020 nicht mehr angefasst. Abgesehen von den laufenden Kosten, eine PostgreSQL-interne C-Erweiterung über jede neue PostgreSQL-Hauptversion hinweg lauffähig zu halten, kann sie grundsätzlich überhaupt nicht gegen eine verwaltete PostgreSQL-Cloud-Instanz (RDS, Cloud SQL, Supabase, Neon und ähnliche) funktionieren — keine von ihnen erlaubt einen eigenen Eintrag in shared_preload_libraries — sodass ein großer und wachsender Anteil der heutigen Benutzer ihn ohnehin nie hätte nutzen können, unabhängig davon, wie gut er gepflegt gewesen wäre.

Das Schreiben und Ausführen von PL/pgSQL-Funktionen selbst ist davon nicht betroffen — siehe PL/pgSQL-Funktionen schreiben. Wenn Sie die PL/pgSQL-Ausführung gegen Ihren eigenen selbst gehosteten PostgreSQL-Server schrittweise durchgehen müssen, ist der ursprüngliche Quellcode von omnidb_plugin weiterhin in der Historie des ursprünglichen Repositorys verfügbar, oder Sie nutzen pldebugger (die aktiv gepflegte Entsprechung, die auch pgAdmin verwendet) direkt, außerhalb von OmniDB.

pglogical (entfernt)

pglogical war eine PostgreSQL-Erweiterung, die ein effizientes logisches Replikationssystem bereitstellte. Das alte Plugin omnidb-pglogical fügte Baumansicht-Knoten und SQL-Vorlagenaktionen (Knoten erstellen, Replikationssets verwalten, Abonnements erstellen und so weiter) für die Arbeit damit hinzu — alles auf dem oben entfernten Plugin-System aufgebaut, sodass es nicht mehr geladen werden kann.

Postgres-BDR (entfernt)

Postgres-BDR („Bi-Directional Replication“) war die Multi-Master-Erweiterung von 2ndQuadrant für PostgreSQL. Das alte Plugin omnidb-bdr bot dieselbe Art von Baumansicht-Integration wie pglogical. Dieselbe Geschichte: Es war ein Plugin, und das Plugin-System, auf dem es beruhte, ist verschwunden.

Postgres-XL (entfernt)

Postgres-XL war ein massiv paralleler, horizontal skalierbarer Fork von PostgreSQL (GTM + Koordinator + Datenknoten). Das alte Plugin omnidb-xl fügte dafür clusterbewusste Baumansicht-Knoten hinzu. Ebenfalls ein Plugin, ebenfalls verschwunden.

Warum keines davon zurückkehrt

Alle drei waren dünne, pluginbasierte Integrationen für Nischen-PostgreSQL-Forks bzw. -Erweiterungen, deren Upstream größtenteils nicht mehr gepflegt wird — weder pglogical noch BDR noch Postgres-XL verzeichneten in den letzten Jahren nennenswerte neue Releases. Das Plugin-System selbst in Go neu aufzubauen würde bedeuten, für ein kleines und schrumpfendes Publikum einen völlig neuen Erweiterungsmechanismus zu entwerfen (kompilierte Plugins, eine Skript-Laufzeitumgebung oder eine Hook-API), was gegenüber dem Rest der Go-Neufassung keine Priorität hatte. Nichts an der Neufassung hindert Sie daran, sich mit einem pglogical-/BDR-/XL-Cluster als gewöhnliche PostgreSQL-Datenbank zu verbinden und Replikationsobjekte von Hand über den regulären SQL-Editor oder den Konsolen-Tab zu verwalten — Sie erhalten lediglich nicht mehr die eigenen Baumansicht-Knoten und SQL-Vorlagen-Shortcuts, die die Plugins früher hinzufügten.

Wo Sie die alten Releases finden

Releases des klassischen OmniDB (bis ca. 2020) mit vollständiger Plugin-Unterstützung sind weiterhin verfügbar, wenn auch nicht mehr gepflegt, im ursprünglichen Repository:

Keines der beiden Repositorys erhält Updates. Wenn Sie heute pglogical, BDR oder Postgres-XL verwalten müssen, ist ein altes Release von dort — betrieben gegen eine zu seiner Ära passende Datenbank — Ihre beste Option; es gibt keinen Migrationspfad von diesem Aufbau in das heutige, Go-basierte OmniDB.