Diese Seite beschreibt Calíope 1.7, die Version, die ich gerade baue. Die 1.6 ist im App Store für Mac, iPad, iPhone, Apple Watch, Apple TV und Apple Vision Pro. Das Changelog sagt, in welcher Version jede Funktion kam.
Fügt jedem Thema einen Button „In Calíope öffnen“ hinzu. Funktioniert nur mit installierter App.
Wie man sich durch Datenbanken, Sammlungen und Dokumente eines MongoDB-Servers bewegt.
Wo es zu finden ist: Workspace › Werkzeuge › Sammlungen
Der Browser zeigt links die Sammlungen der gewählten Datenbank und rechts deren Dokumente, als zusammenklappbare Bäume.
Ein Dokument ist keine Zeile: Zwei benachbarte Dokumente können kein einziges Feld gemeinsam haben — deshalb gibt es kein Spaltenraster. Neben jedem Wert steht sein Typ — ObjectId, decimal128, Datum, Binärdaten —, was in einer schemalosen Datenbank die halbe Information ist.
Zum Bearbeiten auf den Stift tippen: Das Dokument öffnet sich als erweitertes JSON und wird als Ganzes gespeichert, identifiziert über seine _id. Ohne _id lässt es sich weder bearbeiten noch löschen, und das wird gesagt, statt Schaltflächen anzubieten, die ein anderes Dokument treffen würden. Views sind schreibgeschützt und als solche markiert; begrenzte Sammlungen ebenfalls.
Das Menü oben wechselt die Datenbank, und Filtern grenzt die Liste der Sammlungen nach Namen ein. Dokumente kommen in Stapeln zu 50: Die Fußzeile zählt die der Sammlung und die bereits geladenen, und Mehr laden am Ende der Liste holt den nächsten Stapel. Neues Dokument öffnet denselben Editor, leer; Formatieren rückt den Text neu ein und sagt, wenn er sich nicht lesen lässt, warum – ohne ihn anzutasten.
Calíope verbindet sich mit MongoDB 4.0 oder neuer. Bei einer älteren Version wird die Verbindung abgelehnt, mit Angabe der Serverversion.
Mit einem Umgebungsetikett
Ist das Etikett des Profils schreibgeschützt, bietet der Browser weder Neues Dokument noch Bearbeiten oder Löschen von Dokumenten an: Es wird nur gelesen. Bestätigt es Schreibzugriffe, fragt das Speichern eines Dokuments vorher mit dem Etikett vorne, und Löschen, das schon fragte, nennt das Etikett in seiner Frage und fragt nicht zweimal.
Filter, Projektionen, Sortierung und Aggregations-Pipelines.
Wo es zu finden ist: Workspace › Werkzeuge › Abfrage
Die Abfrage hat zwei Modi. „Suchen“ wendet Filter, Projektion und Sortierung an, alle drei als JSON-Dokumente geschrieben. „Aggregation“ führt eine vollständige Pipeline aus, also eine Liste von Stufen.
Das Menü „Sammlung“ wählt, was abgefragt wird, aus der unter „Sammlungen“ gewählten Datenbank, und „Ausführen“ (⌘↩) sendet die Abfrage. Die Fußzeile zählt die geladenen Dokumente und die Millisekunden, die der Server brauchte. Die Felder nehmen erweitertes JSON an, sodass {"$date": …} und {"$oid": …} als Datum und als ObjectId beim Server ankommen, nicht als Text. Eine Pipeline, die keine Liste ist, wird erkannt, bevor etwas gesendet wird; alles andere, was der Server ablehnt, kommt mit seiner eigenen Meldung zurück.
Ergebnisse kommen seitenweise: Mit „Mehr laden“ werden weitere angefordert, und der offene Cursor auf dem Server wird beim Wechsel der Abfrage oder beim Verlassen des Werkzeugs geschlossen — ein verlassener Cursor lebt zehn Minuten weiter und belegt Speicher.
Hier wird nicht bearbeitet: Eine Aggregation hat kein Ursprungsdokument, in das Änderungen zurückgeschrieben werden könnten, und bei einer Projektion gingen die fehlenden Felder beim Speichern verloren. Zum Bearbeiten dient der Browser.
Die Operatoren in Filter und Pipeline haben Einträge: Das Thema Kontexthilfe für SQL-Funktionen erklärt es.
Mit einem Umgebungsetikett Suchen liest nur und ändert sich mit dem Etikett nicht. Eine Aggregation mit $out oder $merge schreibt eine Collection: Ist das Etikett schreibgeschützt, läuft sie nicht und der Hinweis sagt warum; bestätigt es Schreibzugriffe, fragt sie vorher mit dem Etikett vorne.
Indizes ansehen, anlegen und löschen — auch eindeutige, dünn besetzte und ablaufende.
Wo es zu finden ist: Workspace › Werkzeuge › Indizes
Wähle eine Sammlung im Menü Sammlung der Leiste; Views stehen dort nicht, weil eine View keine eigenen Indizes hat; ist die in einem anderen MongoDB-Werkzeug gewählte Sammlung eine View, sagt das Werkzeug das, statt sie zu lesen. Die Liste zeigt jeden Index mit Namen, darunter seine Schlüssel und seine Eigenschaften als Etiketten: eindeutig, dünn besetzt oder mit Ablauf (TTL). Ein Textindex zeigt die Felder, die er abdeckt, jedes mit „text“. Aktualisieren liest die Liste erneut vom Server.
Neuer Index öffnet ein Blatt mit einem Namen, den Schlüsseln als Dokument (1 aufsteigend, -1 absteigend; für Text- und Geo-Indizes gelten auch „text“ und „2dsphere“) und drei Schaltern: eindeutig, dünn besetzt und Ablauf (TTL). Mit Ablauf gibt Sekunden an, wie lange ein Dokument ab dem Datum im indizierten Feld lebt, und es muss eine ganze Zahl sein: sonst bleibt Erstellen ausgegraut. Erstellen schickt ihn an den Server; lehnt der Server ab, etwa weil ein eindeutiger Index doppelte Werte findet, erscheint seine Meldung im Blatt, das offen bleibt.
Der _id-Index lässt sich nicht löschen, weil der Server ihn pflegt — deshalb wird keine Schaltfläche angeboten. Jeder andere wird mit seinem Papierkorb gelöscht, nach einer Bestätigung, und die Abfragen, die ihn nutzten, durchsuchen danach die ganze Sammlung.
Mit einem Umgebungsetikett
Ist das Etikett des Profils schreibgeschützt, werden weder Neuer Index noch der Papierkorb jedes Index angeboten: Die Liste wird weiter gelesen. Bestätigt es Schreibzugriffe, fragt das Anlegen eines Index vorher mit dem Etikett vorne, und Löschen, das schon fragte, nennt das Etikett in seiner Frage und fragt nicht zweimal.
Was auf der relationalen Seite Übersicht, Prozessliste und Benutzer sind.
Wo es zu finden ist: Workspace › Werkzeuge › Server
Hier kommen drei Dinge zusammen, die in MongoDB aus drei Serverbefehlen stammen, einer je Abschnitt des Segmentschalters: Server (Host, Version, Laufzeit, Verbindungen, Speicher und kumulierte Vorgänge), Vorgänge (was der Server gerade tut) und Benutzer (die Benutzer mit ihren Rollen). Nichts aktualisiert sich von selbst: Jeder Abschnitt wird beim Öffnen gelesen, und Aktualisieren liest ihn erneut.
In Vorgänge zeigt jede Zeile die Art des Vorgangs, seinen Namensraum, wie viele Sekunden er schon läuft und die Verbindung, von der er kommt. Inaktive einbeziehen fügt die offenen Verbindungen hinzu, die nichts tun, und die ruhenden Threads des Servers. Vorgang stoppen bittet den Server, einen zu beenden, und wird nur für Vorgänge eines Clients angeboten: Die eigenen Threads des Servers, etwa Checkpointer, haben keine Schaltfläche, weil sie sie nicht anhalten würde.
Benutzer listet alle Benutzer des Servers aus allen Datenbanken als benutzer@datenbank: Ein Benutzer lebt in einer Datenbank. Eine Rolle aus einer anderen Datenbank trägt ihr eigenes @. Eigene Rollen gehören zu einer bestimmten Datenbank, daher werden die der in den anderen Tabs gewählten Datenbank aufgeführt, und der Abschnittstitel nennt sie.
Mit einem Umgebungsetikett
Ist das Etikett des Profils schreibgeschützt, bietet kein Vorgang Vorgang stoppen an: Die drei Bereiche werden weiter gelesen. Bestätigt es Schreibzugriffe, fragt das Stoppen eines Vorgangs vorher mit dem Etikett vorne.
Der MongoDB-Profiler: auf welcher Stufe jede Datenbank steht und was er aufgezeichnet hat.
Wo es zu finden ist: Workspace › Werkzeuge › Profiler
Der Profiler hat drei Stufen: aus, nur die Vorgänge über dem Schwellwert, und alle. Der Schwellwert steht in Millisekunden —nicht in Sekunden wie bei MySQL— und die Abtastrate zwischen 0 und 1 sagt, welcher Anteil der langsamen Vorgänge aufgezeichnet wird: unter 1 verwirft der Server langsame Vorgänge absichtlich.
Die Stufe gehört zu jeder Datenbank, nicht zum Server. Deshalb trägt die Leiste ihre Datenbankauswahl, und alles Gelesene und Geschriebene bezieht sich auf die gewählte. Und sie liegt im Speicher: ein Neustart des Servers setzt sie auf das zurück, was seine Startkonfiguration sagt.
Das Aufgezeichnete landet in „system.profile“, einer begrenzten Sammlung von 1 MB je Datenbank: ein Fenster auf die letzten Vorgänge, keine Historie, und ihre Dokumente haben kein „_id“, werden also gelesen und nicht bearbeitet. Sie zu leeren bedeutet, die Sammlung zu verwerfen, und dafür muss der Profiler kurz aus sein: Calíope schaltet ihn aus, verwirft sie und stellt die vorherige Stufe wieder her.
Darunter zeigt die Liste, was „system.profile“ enthält, das Neueste zuerst: Zeit, Vorgang, Namensraum, Millisekunden und, wenn der Server sie aufzeichnet, den Plan, die geprüften Dokumente und Schlüssel, die zurückgegebenen Dokumente und den Client. Gelesen werden nur die letzten 200, und die Fußzeile sagt es. Ein Doppelklick oder Return auf dem Mac oder anderswo ein Tippen auf die Zeile öffnet das ganze aufgezeichnete Dokument; von dort und aus dem Menü der Zeile kopiert „JSON kopieren“ es und „Kopieren und Abfrage öffnen“ nur seinen Befehl und öffnet Abfrage. „Automatisch aktualisieren (10 s)“ liest alle zehn Sekunden alles neu, „Gelesen“ sagt, wann zuletzt, und „Aktualisieren“ lädt auch die Liste der Datenbanken neu.
„Stufe“, „Schwellwert“ und „Abtastrate“ ändern nichts vor „Anwenden“, und danach liest Calíope den Profiler neu: Der Server antwortet mit den Werten von vorher, nicht mit den neuen.
Es gibt keine Ansicht „nach Anweisung“ wie im relationalen Protokoll langsamer Abfragen: MongoDB veröffentlicht keine aggregierte Zusammenfassung nach Vorgangsform, und sie im Client über ein 1-MB-Fenster zu berechnen würde mehr behaupten, als die Daten tragen.
In geteiltem Atlas und hinter „mongos“ lassen sich Stufe 1 und 2 nicht setzen: dort nimmt der Server nur 0 an.
Mit einem Umgebungsetikett
Ist das Etikett des Profils schreibgeschützt, werden Profiler dieser Datenbank ändern und Profiler leeren nicht angezeigt: Es bleiben der Zustand und die aufgezeichneten Vorgänge. Bestätigt es Schreibzugriffe, fragt Anwenden vorher mit dem Etikett vorne, und Leeren, das schon fragte, nennt das Etikett in seiner Frage und fragt nicht zweimal.
Der Ausweg für alles, was die Oberfläche nicht abdeckt.
Wo es zu finden ist: Workspace › Werkzeuge › Befehle
In MongoDB ist ein Befehl ein Dokument: Dieses Werkzeug schickt ihn unverändert und zeigt die vollständige Antwort.
Es deckt ab, was keine Oberfläche leistet: eine Sammlung prüfen, Statistiken abrufen, eine Abfrage erklären oder jeden Administrationsbefehl. Du schreibst das Dokument in den Editor und klickst auf Ausführen (⌘↩). Das Menü Beispiele bringt die häufigsten fertig mit; die, die auf eine Sammlung wirken, tragen „SAMMLUNG“ dort, wo ihr Name hingehört.
Das Menü am Anfang der Leiste wählt die Zieldatenbank, denn manche Befehle werden nur auf „admin“ angenommen: getCmdLineOpts zum Beispiel, das die Optionen zeigt, mit denen der Server gestartet wurde.
Die Antwort kommt als Baum, und der Pfeil neben einem Unterdokument oder einem Array öffnet es. Ist der Text kein gültiges JSON, sagt Calíope, wo, bevor etwas gesendet wird; lehnt der Server den Befehl ab, nennt die Warnung Code und Namen. Ein Schreibvorgang kann auch zur Hälfte angenommen werden: Ein insert, das ein Validator ablehnt, antwortet trotzdem mit ok: 1, und das abgelehnte Dokument steht in writeErrors, mit der verletzten Regel.
Mit einem Umgebungsetikett
Das Werkzeug wird auch bei einer schreibgeschützten Verbindung angeboten, weil es zum Lesen dient. Calíope führt eine Liste der Befehle, die lesen —find, aggregate ohne $out und $merge, count, distinct, listCollections, listIndexes, listDatabases, dbStats, collStats, serverStatus, buildInfo, hello, isMaster, ping, explain, getLog, currentOp, connectionStatus, hostInfo, getParameter, getCmdLineOpts, validate, usersInfo, rolesInfo, getMore und killCursors—, und alles andere gilt als Schreibzugriff, auch ein unbekannter Befehl. Ist das Etikett schreibgeschützt, wird ein schreibender Befehl nicht gesendet und die Antwort sagt warum; bestätigt es Schreibzugriffe, fragt er vorher mit dem Etikett vorne.
Die Datenbank und die Collection, die du in Sammlungen wählst, verwenden auch Abfrage, Indizes und die übrigen MongoDB-Werkzeuge der Sitzung.
Wo es zu finden ist: Workspace › Werkzeuge › Sammlungen
Die Datenbank und die Collection, die du in Sammlungen wählst, gehören zur Sitzung, nicht zum Tab: Abfrage, Indizes und die übrigen MongoDB-Werkzeuge, die mit einer Collection arbeiten, nutzen dieselben, und sie bleiben beim Tab-Wechsel erhalten.
Ein Wechsel der Datenbank im Menü hebt die Auswahl der Collection auf, damit nichts aus einer Collection einer anderen Datenbank liest. Beim Öffnen der Sitzung ist die Datenbank des Profils vorausgewählt oder, wenn es keine hat, die erste, die nicht admin, config oder local ist.
In einer MongoDB-Sitzung wählt ein Bericht seine Collection und seine Form —einen Filter mit find oder eine Pipeline mit aggregate—, beide in Extended JSON.
Wo es zu finden ist: Workspace › Werkzeuge › Berichte
In einer MongoDB-Sitzung beginnt ein neuer Bericht als find (Filter) mit leerer Collection. Über dem Text stehen Collection und Form: Das erste legt fest, aus welcher Collection gelesen wird, das zweite wählt zwischen find (Filter) und aggregate (Pipeline).
Beides wird in Extended JSON geschrieben. Eine Pipeline muss ein Array sein und jede Stufe ein Objekt; sonst wird der Bericht vor der Ausführung abgelehnt. Parameter schreibst du als "$$name". Ein Wechsel der Form beginnt den Text von vorn: {} für einen Filter und [] für eine Pipeline.
Ein MongoDB-Bericht hat weder Stoppen noch Planen: Er lässt sich nicht mittendrin abbrechen, und geplant werden nur relationale Berichte.