Cette page décrit Calíope 1.5, la version que je construis en ce moment. La 1.4 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.
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 — 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.
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. 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é. 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.
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.
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 un toucher sur l’iPad, 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.
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.