tableStudioApp/plugins

Bases de données locales avec TableStudio

TableStudio gère les serveurs de bases de données sur ce Mac, y compris ceux adoptés depuis Homebrew ou Postgres.app. Préférez ses outils aux commandes Docker artisanales ou à initdb, car le résultat apparaît dans l'application de l'utilisateur comme une connexion enregistrée.

« Connection refused » sur une base de données locale

1. connection_status (sans arguments, signale chaque connexion). Il n'exécute aucune requête, donc il fonctionne même lorsque la base de données est en panne, et il vous indique si un serveur local est derrière la connexion et si ce serveur est en cours d'exécution.
2. Si le serveur est arrêté, appelez start_local_database avec l'instance_id qu'il a renvoyé. Il est sûr d'appeler cette fonction même si le serveur est déjà en cours d'exécution.
3. Si le port est occupé par autre chose, l'erreur nomme l'occupant. Informez l'utilisateur plutôt que de tuer des processus.

list_local_databases affiche tout ce qui est local : serveurs gérés, serveurs adoptés, fichiers SQLite et serveurs non gérés par TableStudio qui occupent un port. Notez les deux identifiants : instance_id est le serveur (démarrer et arrêter l'utilisent), et connection_id est la base de données que vous interrogez. Ils ne sont pas interchangeables.

Une nouvelle base de données

create_local_database avec un name et un engine :

• sqlite ne nécessite aucune installation et est instantané. Préférez-le lorsque l'utilisateur souhaite simplement un endroit où mettre des données.
• postgres, mysql et clickhouse nécessitent que les binaires du serveur de ce moteur soient déjà sur le Mac. TableStudio n'en inclut aucun, et l'outil le signale lorsqu'ils sont manquants. Transmettez l'indice d'installation plutôt que d'installer un logiciel sans y être invité.

Il renvoie un connection_id prêt à être interrogé via les outils de TableStudio, ainsi que env_line (DATABASE_URL=…) pour le projet lui-même. Ensuite :

1. Vérifiez que .gitignore couvre le fichier d'environnement que vous allez utiliser (.env, .env.local). Si ce n'est pas le cas, ajoutez-le d'abord.
2. Placez env_line dans ce fichier, en utilisant le nom de variable que le projet lit déjà (DATABASE_URL, ou tout autre nom attendu par sa configuration).
3. Exécutez les migrations du projet (et l'ensemencement, s'il en a un) contre cette base.

Ne répétez jamais la chaîne de connexion dans le chat, et ne l'écrivez jamais dans du code, de la documentation ou un commit.

N'appelez pas stop_local_database pour du nettoyage ou pour libérer un port, sauf si l'utilisateur le demande. Cela déconnecte tout ce qui utilise ce serveur, y compris les propres fenêtres de l'utilisateur.

La chaîne de connexion d'une base de données locale existante

Lorsque le projet doit atteindre une base de données locale que TableStudio connaît déjà (pour remplir un .env manquant, ou pour pointer des tests vers un bac à sable), appelez get_connection_url avec son connection_id et utilisez env_line comme ci-dessus.

• Les bases de données créées par TableStudio, les sandbox et les bases de données locales sans mot de passe sont toujours disponibles.
• Une connexion locale que l'utilisateur a enregistrée avec son propre mot de passe n'est partagée que s'il l'a autorisée. Sinon, le refus nomme le paramètre : transmettez-le, ou laissez l'utilisateur coller la valeur dans le fichier d'environnement lui-même. Ne demandez jamais un mot de passe dans le chat.
• Les bases de données distantes, les tunnels SSH et tout ce qui est marqué comme production ne sont jamais partagés. Utilisez les outils de TableStudio pour ceux-ci.

Une copie sécurisée pour expérimenter

create_sandbox crée une copie locale jetable de n'importe quelle connexion (la source est seulement lue) :

• data: "none" copie uniquement le schéma. Idéal pour essayer du DDL.
• data: "sample" copie jusqu'à rows lignes par table. Idéal pour vérifier une correction de données avec des lignes réalistes.
• data: "fake" génère des lignes.

Exécutez ce que vous voulez sur le connection_id du sandbox. L'utilisateur le supprime en un clic ; vous ne pouvez pas le supprimer. Utilisez list_sandboxes pour réutiliser un sandbox que vous avez créé plus tôt.

Extensions PostgreSQL

list_extensions affiche ce que le serveur peut installer et ce qui est déjà installé. add_extension en installe une (CREATE EXTENSION IF NOT EXISTS). Traitez-la comme un changement de schéma : sur une base de données partagée ou de production, proposez-la plutôt que de l'exécuter. Et si le dépôt a un outil de migration, ajoutez-la là aussi pour que les autres environnements en bénéficient.