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.
Recherchez un texte dans toutes les colonnes de texte d’une base et remplacez-le en masse, avec un aperçu du résultat.
Où le trouver : Espace de travail › Outils › Rechercher
Recherche globale parcourt les tables que vous sélectionnez et indique dans quelles colonnes un texte apparaît, combien de fois et sous quelle forme.
Utilisation
1. Choisissez la base de données dans l’en-tête.
2. Sélectionnez les tables dans l’arborescence de gauche.
3. Saisissez le texte et appuyez sur Rechercher.
4. Dépliez une table pour voir les colonnes concernées et quelques lignes d’exemple.
SQL Server
Dans SQL Server, la liste montre chaque base avec son schéma (demo.dbo), et la recherche parcourt ce schéma.
PostgreSQL
Dans PostgreSQL, la liste montre les schémas de la base à laquelle vous êtes connecté, et la recherche en parcourt un.
Chaque correspondance peut être ouverte dans l’éditeur SQL avec son SELECT déjà écrit, pour la voir en contexte ou l’affiner à la main.
Une base par recherche. C’est délibéré : chercher dans tout un serveur multiplie le parcours et rend les résultats impossibles à relire. Pour plusieurs bases, répétez la recherche.
On peut l’arrêter. Pendant l’exécution, l’en-tête affiche l’avancement par table et un bouton Arrêter ; la recherche apparaît aussi dans le panneau Activité, vous pouvez donc changer d’onglet sans la perdre.
Mots-clés : rechercher, remplacer, texte, global, toutes les tables, masse
Chercher à l’intérieur d’une colonne ne peut pas utiliser d’index : tout est lu, et Calíope vous dit combien avant de commencer.
Rechercher un texte à l’intérieur d’une colonne ne peut tirer parti d’aucun index. Ce n’est pas une limite de Calíope : c’est le fonctionnement des bases relationnelles. Un index sait trier par le début d’une valeur, pas par ce qui se trouve au milieu.
Chaque recherche lit donc toutes les lignes de toutes les tables sélectionnées. D’où l’avertissement, avant de commencer, indiquant combien de tables seront parcourues et quelle place elles occupent.
Pour accélérer
- Ne sélectionnez que les tables où la recherche a du sens.
- Commencez par les petites tables pour valider le texte, puis élargissez.
- Si le serveur est derrière un tunnel SSH, la latence se fera sentir.
La taille affichée provient du catalogue du serveur : c’est une estimation, qui peut être imprécise sur des tables très actives.
Mots-clés : coût, lent, index, performance, taille, parcours, grandes tables
Pourquoi on trouve plus de lignes qu’on n’en remplace
La recherche suit les règles du serveur et ignore la casse ; le remplacement non. Calíope affiche l’écart exact.
C’est le piège le plus important de cet outil, et c’est pourquoi Calíope l’affiche au lieu de le cacher.
Rechercher et remplacer ne comparent pas de la même façon. La recherche ignore en général la casse : chercher foo trouve aussi Foo et FOO. Le remplacement, lui, distingue toujours : il ne changerait que foo.
MySQLMariaDBAurora
Ce qui décide la recherche, c’est la collation de la colonne, qui dans la plupart des bases ignore la casse ; le REPLACE() qui écrit compare octet par octet.
SQL Server
La recherche suit la collation de la colonne, qui ignore presque toujours la casse. REPLACE() la suivrait aussi, alors Calíope le fait comparer avec la variante de cette même collation qui distingue la casse et les accents : ce que l’avertissement compte est ce que cette écriture changerait.
PostgreSQL
La recherche utilise ILIKE, qui ignore la casse quelle que soit la collation ; le replace() qui écrit compare caractère par caractère.
Sans avertissement, le résultat est un remplacement qui annonce 300 lignes et en change 100, sans échec ni message d’erreur. Les données restent à moitié migrées.
Ce que fait Calíope
- Il compte les deux séparément dans la même requête et affiche l’avertissement avec les deux chiffres.
- À côté du total de chaque colonne figure le nombre de lignes réellement remplaçables.
- L’aperçu ne montre que les lignes qui vont changer.
Ce que vous pouvez faire
- Activez Respecter la casse : ce que vous trouvez est alors exactement ce qui sera remplacé, et l’avertissement disparaît.
- Ou faites plusieurs passes, une par forme écrite (foo, Foo, FOO).
Toutes les colonnes de texte sont parcourues, mais certaines ne peuvent pas être écrites ; Calíope dit lesquelles et pourquoi.
La recherche couvre toutes les colonnes de texte : texte court et long, listes fermées et documents JSON.
Le remplacement n’est pas proposé dans quatre cas, et la colonne porte alors un cadenas avec son motif :
Motif
Pourquoi
Le serveur calcule la colonne
Sa valeur vient d’autres colonnes ; l’écrire n’a aucun effet
N’accepte que les valeurs d’une liste fermée
Un remplacement peut sortir de la liste, et certains serveurs le transforment en texte vide sans prévenir
Fait partie de la clé primaire
La modifier peut casser les relations avec d’autres tables
Possède un index unique
La nouvelle valeur peut entrer en collision avec une valeur existante
SQL Server
SQL Server n’a pas de colonnes limitées à une liste fermée : il n’y a donc ici que trois cas. Les colonnes xml sont remplacées et doivent rester du XML valide : le serveur refuse l’écriture qui le casse.
PostgreSQL
Dans PostgreSQL, les listes fermées sont les types ENUM. Les colonnes json et jsonb sont remplacées et doivent rester du JSON valide : le serveur refuse l’écriture qui le casse.
Les tables sans clé primaire ne sont pas remplacées, et c’est indiqué dans la fenêtre de confirmation. Sans clé, impossible d’identifier chaque ligne, et une écriture trop large toucherait des enregistrements que personne n’a vus.
Les vues sont exclues. Certaines acceptent l’écriture, mais déterminer lesquelles suppose d’analyser leur définition, et le risque n’en vaut pas la peine.
Le remplacement passe toujours par un aperçu calculé par le serveur, et vous pouvez emporter le SQL dans l’éditeur au lieu de l’exécuter.
Un remplacement global est une écriture massive sur des données que vous n’avez pas vues une à une. C’est pourquoi il ne peut pas être lancé sans passer par la fenêtre de vérification.
Ce que vous voyez avant toute écriture
1. Les tables et colonnes concernées, et le nombre de lignes de chacune.
2. L’aperçu avant → après, ligne par ligne.
3. Les avertissements applicables : l’écart entre le trouvé et le remplaçable, les colonnes bloquées et les clés étrangères qui dépendent de ce que vous allez modifier.
L’aperçu est calculé par le serveur, avec l’opération même qui effectuera l’écriture. Ce n’est pas une simulation : ce que vous voyez est littéralement ce qui sera enregistré, y compris les troncatures par longueur maximale que vous découvririez sinon trop tard.
Voir le script vous donne le SQL complet à copier et exécuter vous-même, ou à conserver. Ce bouton n’écrit rien.
Deux garde-fous supplémentaires
- Au-delà de mille lignes, il faut saisir le nombre pour confirmer.
- Chaque table est écrite dans sa propre transaction, puis les lignes modifiées sont comparées aux lignes annoncées. En cas d’écart, vous en êtes informé : à la fin, une ligne sous le champ de recherche indique les lignes remplacées et, s’il en manque, dans quelles tables.
Il n’y a pas d’annulation. Si les données comptent, faites d’abord une sauvegarde depuis l’outil Sauvegarde.