Cette page décrit Calíope 1.7, la version que je construis en ce moment. La 1.6 est sur l'App Store pour Mac, iPad, iPhone, Apple Watch, Apple TV et Apple Vision Pro. Le changelog indique dans quelle version chaque fonction est arrivée.
Ajoute un bouton « Ouvrir dans Calíope » à chaque sujet. Ne fonctionne qu'avec l'app installée.
Comment naviguer dans les bases, collections et documents d’un serveur MongoDB.
Où le trouver : Espace de travail › Outils › Collections
L’explorateur affiche à gauche les collections de la base choisie et à droite leurs documents, sous forme d’arbres repliables.
Un document n’est pas une ligne : deux documents voisins peuvent ne partager aucun champ, d’où l’absence de grille de colonnes. À côté de chaque valeur figure son type — ObjectId, decimal128, date, binaire — ce qui, dans une base sans schéma, représente la moitié de l’information.
Pour modifier, appuyez sur le crayon : le document s’ouvre en JSON étendu et il est enregistré en entier, identifié par son _id. Sans _id, il ne peut être ni modifié ni supprimé, et cela est indiqué au lieu de proposer des boutons qui toucheraient un autre document. Les vues sont en lecture seule et signalées comme telles ; les collections plafonnées le sont aussi.
Le menu du haut change de base, et Filtrer restreint par nom la liste des collections. Les documents arrivent par lots de 50 : le pied de page compte ceux de la collection et ceux déjà chargés, et Charger plus, en fin de liste, ramène le lot suivant. Nouveau document ouvre le même éditeur, vide ; Formater réindente le texte et, s’il ne peut pas être lu, explique pourquoi sans y toucher.
Calíope se connecte à MongoDB 4.0 ou version ultérieure. Avec une version plus ancienne, la connexion est refusée en indiquant la version du serveur.
Avec une étiquette d’environnement
Si l’étiquette du profil est en lecture seule, l’explorateur ne propose ni Nouveau document, ni modifier, ni supprimer un document : on ne fait que lire. Si elle confirme les écritures, enregistrer un document demande d’abord, avec l’étiquette devant, et supprimer, qui demandait déjà, la nomme dans sa question et ne demande pas deux fois.
Filtres, projections, tri et pipelines d’agrégation.
Où le trouver : Espace de travail › Outils › Requête
L’outil de requête a deux modes. « Rechercher » applique un filtre, une projection et un tri, tous trois écrits comme des documents JSON. « Agrégation » exécute un pipeline complet, c’est-à-dire une liste d’étapes.
Le menu « Collection » choisit ce qu’on interroge, dans la base choisie dans « Collections », et « Exécuter » (⌘↩) l’envoie. Le pied de page compte les documents chargés et les millisecondes qu’a mises le serveur. Les champs acceptent le JSON étendu : {"$date": …} et {"$oid": …} arrivent au serveur comme une date et un ObjectId, pas comme du texte. Un pipeline qui n’est pas une liste est détecté avant tout envoi ; le reste de ce que le serveur refuse revient avec son propre message.
Les résultats arrivent par pages : demandez-en davantage avec « Charger plus » ; le curseur ouvert côté serveur est fermé au changement de requête ou quand on quitte l’outil — abandonné, il reste vivant dix minutes en occupant de la mémoire.
Les résultats ne se modifient pas ici : une agrégation n’a pas de document d’origine où réécrire les changements, et avec une projection les champs absents seraient perdus à l’enregistrement. Pour modifier, utilisez l’explorateur.
Les opérateurs écrits dans le filtre et le pipeline ont leur fiche : le sujet Aide contextuelle pour les fonctions SQL l'explique.
Avec une étiquette d’environnement Rechercher ne fait que lire et ne change pas avec l’étiquette. Une agrégation avec $out ou $merge écrit une collection : si l’étiquette est en lecture seule, elle ne s’exécute pas et l’avis dit pourquoi, et si elle confirme les écritures, elle demande d’abord, avec l’étiquette devant.
Voir, créer et supprimer des index, y compris uniques, clairsemés et à expiration.
Où le trouver : Espace de travail › Outils › Index
Choisissez une collection dans le menu Collection de la barre ; les vues n’y figurent pas, car une vue n’a pas d’index propres ; si la collection choisie dans un autre outil MongoDB est une vue, l’outil le dit au lieu de la lire. La liste montre chaque index par son nom, avec ses clés en dessous et ses propriétés en étiquettes : unique, clairsemé ou avec expiration (TTL). Un index de texte montre les champs qu’il couvre, chacun avec « text ». Actualiser relit la liste sur le serveur.
Nouvel index ouvre une feuille avec un Nom, les Clés écrites comme un document (1 pour croissant, -1 pour décroissant, et « text » ou « 2dsphere » sont acceptés pour les index de texte et géospatiaux) et trois interrupteurs : unique, clairsemé et Expiration (TTL). Avec une expiration, Secondes est la durée de vie d’un document à partir de la date du champ indexé, et ce doit être un nombre entier : sinon Créer reste désactivé. Créer l’envoie au serveur ; si le serveur le refuse, par exemple parce qu’un index unique trouve des valeurs répétées, son message apparaît dans la feuille, qui reste ouverte.
L’index _id ne peut pas être supprimé car le serveur le maintient : aucun bouton n’est proposé. Tout autre index se supprime avec sa corbeille, après une confirmation, et les requêtes qui l’utilisaient parcourront toute la collection.
Avec une étiquette d’environnement
Si l’étiquette du profil est en lecture seule, ni Nouvel index ni la corbeille de chaque index ne sont proposés : la liste se lit toujours. Si elle confirme les écritures, créer un index demande d’abord, avec l’étiquette devant, et supprimer, qui demandait déjà, la nomme dans sa question et ne demande pas deux fois.
Ce qui, côté relationnel, correspond au tableau de bord, aux processus et aux utilisateurs.
Où le trouver : Espace de travail › Outils › Serveur
Cet outil réunit trois choses qui, sous MongoDB, proviennent de trois commandes du serveur, une par section du contrôle segmenté : Serveur (hôte, version, durée de fonctionnement, connexions, mémoire et opérations cumulées), Opérations (ce que le serveur fait en ce moment) et Utilisateurs (les utilisateurs avec leurs rôles). Rien ne s’actualise tout seul : chaque section est lue à son ouverture, et Actualiser la relit.
Dans Opérations, chaque ligne indique le type d’opération, son espace de noms, depuis combien de secondes elle tourne et la connexion d’où elle vient. Inclure les inactives ajoute les connexions ouvertes qui ne font rien et les threads du serveur au repos. Arrêter l’opération demande au serveur d’en terminer une, et n’est proposé que pour les opérations venant d’un client : les threads du serveur lui-même, comme Checkpointer, n’ont pas de bouton, car il ne les arrêterait pas.
Utilisateurs liste tous les utilisateurs du serveur, de toutes les bases, sous la forme utilisateur@base : un utilisateur vit dans une base. Un rôle d’une autre base porte son propre @. Les rôles personnalisés appartiennent à une base précise, donc ceux listés sont ceux de la base choisie dans les autres onglets, et le titre de la section la nomme.
Avec une étiquette d’environnement
Si l’étiquette du profil est en lecture seule, aucune opération ne propose Arrêter l’opération : les trois sections se lisent toujours. Si elle confirme les écritures, arrêter une opération demande d’abord, avec l’étiquette devant.
Le profileur MongoDB : à quel niveau se trouve chaque base et ce qu’il a enregistré.
Où le trouver : Espace de travail › Outils › Profileur
Le profileur a trois niveaux : éteint, seulement les opérations qui dépassent le seuil, et toutes. Le seuil est en millisecondes —pas en secondes, comme celui de MySQL— et l’échantillonnage, entre 0 et 1, indique quelle proportion des lentes est enregistrée : en dessous de 1, le serveur écarte des opérations lentes à dessein.
Le niveau appartient à chaque base, pas au serveur. C’est pourquoi la barre porte son sélecteur de base et tout ce qui est lu et écrit se rapporte à celle qui est choisie. Et il vit en mémoire : un redémarrage du serveur le ramène à ce que dit sa configuration de démarrage.
Ce qui est enregistré va dans « system.profile », une collection plafonnée de 1 Mo par base : c’est une fenêtre sur les dernières opérations, pas un historique, et ses documents n’ont pas d’« _id », donc ils se lisent et ne s’éditent pas. La vider supprime la collection, et cela demande d’éteindre un instant le profileur : Calíope l’éteint, la supprime et rétablit le niveau qui était là.
En dessous, la liste montre ce que contient « system.profile », du plus récent au plus ancien : heure, opération, espace de noms, millisecondes et, quand le serveur les note, le plan, les documents et les clés examinés, les documents retournés et le client. Seules les 200 dernières sont lues, et le pied de liste le dit. Un double clic ou Retour sur le Mac, ou ailleurs un toucher sur la ligne, ouvre le document enregistré en entier ; de là, et depuis le menu de la ligne, « Copier le JSON » le copie et « Copier et ouvrir Requête » copie seulement sa commande et ouvre Requête. « Rafraîchir seul (10 s) » relit tout toutes les dix secondes, « Lu » dit quand ce fut la dernière fois, et « Actualiser » recharge aussi la liste des bases.
« Niveau », « Seuil » et « Échantillonnage » ne changent rien avant « Appliquer », et ensuite Calíope relit le profileur : le serveur répond avec les valeurs d’avant, pas avec les nouvelles.
Il n’y a pas de vue « par instruction » comme dans le journal des requêtes lentes relationnel : MongoDB ne publie aucun résumé agrégé par forme d’opération, et le calculer côté client sur une fenêtre de 1 Mo affirmerait plus que la donnée ne le permet.
Sur Atlas partagé et derrière « mongos », les niveaux 1 et 2 ne peuvent pas être réglés : là, le serveur n’accepte que 0.
Avec une étiquette d’environnement
Si l’étiquette du profil est en lecture seule, ni Modifier le profileur de cette base ni Vider le profileur ne s’affichent : restent l’état et les opérations enregistrées. Si elle confirme les écritures, appliquer demande d’abord, avec l’étiquette devant, et vider, qui demandait déjà, la nomme dans sa question et ne demande pas deux fois.
La porte de sortie pour ce que l’interface ne couvre pas.
Où le trouver : Espace de travail › Outils › Commandes
Sous MongoDB, une commande est un document : cet outil l’envoie telle quelle et affiche la réponse complète.
Il couvre ce qu’aucune interface ne fait : valider une collection, demander des statistiques, expliquer une requête ou toute commande d’administration. Vous saisissez le document dans l’éditeur et appuyez sur Exécuter (⌘↩). Le menu Exemples propose les plus fréquentes, déjà écrites ; celles qui agissent sur une collection portent « COLLECTION » à la place de son nom.
Le menu au début de la barre choisit la base de destination, car certaines commandes ne sont acceptées que sur « admin » : getCmdLineOpts, par exemple, qui affiche les options avec lesquelles le serveur a démarré.
La réponse arrive sous forme d’arbre, et la flèche à côté d’un sous-document ou d’un tableau l’ouvre. Si le texte n’est pas du JSON valide, Calíope indique où avant d’envoyer quoi que ce soit ; si le serveur rejette la commande, l’avertissement porte son code et son nom. Une écriture peut aussi être acceptée à moitié : un insert qu’un validateur rejette répond quand même ok: 1, et le document rejeté arrive dans writeErrors, avec la règle enfreinte.
Avec une étiquette d’environnement
L’outil est proposé aussi sur une connexion en lecture seule, car il sert à lire. Calíope garde une liste des commandes qui lisent —find, aggregate sans $out ni $merge, count, distinct, listCollections, listIndexes, listDatabases, dbStats, collStats, serverStatus, buildInfo, hello, isMaster, ping, explain, getLog, currentOp, connectionStatus, hostInfo, getParameter, getCmdLineOpts, validate, usersInfo, rolesInfo, getMore et killCursors— et tout le reste compte comme une écriture, y compris une commande inconnue. Si l’étiquette est en lecture seule, une commande qui écrit ne part pas et la réponse dit pourquoi, et si elle confirme les écritures, elle demande d’abord, avec l’étiquette devant.
La base et la collection choisies dans Collections sont celles qu’utilisent Requête, Index et les autres outils MongoDB de la session.
Où le trouver : Espace de travail › Outils › Collections
La base et la collection choisies dans Collections appartiennent à la session, pas à l’onglet : Requête, Index et les autres outils MongoDB qui travaillent sur une collection utilisent les mêmes, et elles sont conservées quand vous changez d’onglet.
Changer de base dans le menu désélectionne la collection, pour que rien ne lise une collection d’une autre base. À l’ouverture de la session, la base du profil est présélectionnée ou, à défaut, la première qui n’est ni admin, ni config, ni local.
Mots-clés : collection, base de données, MongoDB, session, outils
Dans une session MongoDB, un rapport choisit sa collection et sa forme —un filtre avec find ou un pipeline avec aggregate—, tous deux en Extended JSON.
Où le trouver : Espace de travail › Outils › Rapports
Dans une session MongoDB, un nouveau rapport naît en find (filtre) avec la collection vide. Au-dessus du texte se trouvent Collection et Forme : le premier indique la collection lue, le second choisit entre find (filtre) et aggregate (pipeline).
Les deux s’écrivent en Extended JSON. Un pipeline doit être un tableau, et chaque étape un objet ; sinon, le rapport est refusé avant de s’exécuter. Les paramètres s’écrivent "$$nom". Changer de forme repart d’un texte vide : {} pour un filtre et [] pour un pipeline.
Un rapport MongoDB n’a ni Arrêter ni Planifier : il ne s’annule pas en cours de route, et la planification est réservée aux rapports relationnels.