Le client d'application open source pour les bases de données de schéma. Exécutez-le à côté de votre propre PostgreSQL, appairez-le une fois, et il maintient la convergence de cette base avec vos enrichissements — en s'amorçant à partir d'un instantané, puis en appliquant un flux delta en direct sur un unique WebSocket sortant. Votre chaîne de connexion ne quitte jamais votre machine.
Chaque instruction est protégée par révision, de sorte qu'un traitement par lot redistribué converge vers les mêmes lignes. Une erreur SQL annule le traitement par lot et l'interrompt — un delta corrompu n'est jamais ignoré silencieusement.
Le client récupère l'état, pas les opérations : chaque delta transporte la ou les lignes actuelles complètes d'une entité modifiée sous la forme d'un INSERT … ON CONFLICT … DO UPDATE idempotent, de sorte que la cible converge même si un traitement par lot a été manqué.
Les bases de données de schéma peuvent être consommées de plusieurs façons — n8n, Make.com, MCP, webhooks bruts ou le flux delta REST. Le client de synchronisation est la voie entièrement automatisée : le moins à construire et le moins à exposer.
Aucun scénario n8n, aucun cron, aucun code de liaison. Appairez une fois et le client s'amorce à partir de l'instantané, puis applique chaque delta dès son arrivée.
La chaîne de connexion est passée en ligne de commande ou stockée localement en mode 600 — elle n'est jamais envoyée à Entity Enricher. Le client ne se connecte que vers l'extérieur.
Chaque delta est un upsert idempotent, protégé par révision. Si le client s'arrête en plein traitement par lot, le traitement par lot est redistribué après l'expiration de son bail et sa réapplication converge vers les mêmes lignes.
Une erreur SQL annule le traitement par lot, signale le delta en échec sur la page Bases de données et se termine avec un code non nul — un delta empoisonné ne peut jamais être ignoré silencieusement.
Enregistrez d'abord une base de données sur un schéma, puis appairez un client et exécutez-le à côté de votre base de données.
Sur la page Bases de données, enregistrez une base de données sur le schéma que vous souhaitez refléter et vérifiez ses clés de base de données. Consultez Bases de données pour le modèle complet. Cette étape déclare le dialecte cible que le client appliquera.
Téléchargez un binaire signé depuis les Versions, ou compilez depuis les sources (Go ≥ 1.23).
go build -o ee-database .
Le code source et les versions signées se trouvent sur TOT-Concept/ee-database (MIT).
Exécutez ee-database pair. Un onglet de navigateur s'ouvre sur /database/connect avec un code court — confirmez-le, et choisissez quelle base de données ce client doit synchroniser.
ee-database pair --server https://entityenricher.ai Open this URL in your browser to confirm pairing: https://entityenricher.ai/database/connect?code=7QX-KP2 Code: 7QX-KP2 Waiting for confirmation...
Vous préférez un jeton ? Émettez-en un sur la page Bases de données (Client de synchronisation → Appairer un client) et transmettez-le directement : ee-database pair --server … <refresh-token>.
Lors de la première exécution, le client récupère l'instantané .sql et l'applique, puis se connecte et diffuse les deltas. --save-dsn stocke la chaîne de connexion localement afin que les exécutions ultérieures ne nécessitent aucun argument.
ee-database run --dsn "postgres://user:pass@localhost:5432/mydb" --save-dsn
« À côté » signifie adjacent au réseau, pas sur le serveur de base de données : toute machine ou tout conteneur pouvant atteindre le DSN convient — y compris PostgreSQL géré dans le cloud (Azure, OVHcloud, AWS RDS…), qui impose généralement TLS : …/mydb?sslmode=require.
Les deltas quittent Entity Enricher via une file d'attente sortante FIFO stricte, propre à chaque base de données. Le serveur loue la fenêtre visible pendant 120 secondes et la transmet en un seul lot ; le client applique l'ensemble du lot dans une seule transaction et répond ack , ce qui fait avancer le curseur et déclenche immédiatement la fenêtre suivante. Un client qui meurt en cours de lot est couvert par l'expiration du bail et une retransmission côté serveur — rien n'est perdu ni validé deux fois.
L'amorçage et le régime permanent partagent un seul chemin de code. Ignorez l'amorçage avec --skip-bootstrap si votre base de données est déjà initialisée.
Chaque instruction porte un _sync_revision afin qu'une ligne plus ancienne n'écrase jamais une plus récente, même dans le désordre.
Une erreur SQL enregistre l'id du delta en échec sur la page Bases de données → carte du client de synchronisation, et le processus se termine avec un code non nul pour que votre superviseur le redémarre.
Le dialecte cible est fixé par l'enregistrement de la base de données de schéma dans Entity Enricher — le client applique le SQL que le serveur génère, quel qu'il soit. PostgreSQL est le dialecte de lancement ; les pilotes MySQL et SQLite sont déjà inclus pour l'arrivée de leurs générateurs SQL. L'application multi-instructions est gérée par pilote (protocole simple pgx, multiStatements MySQL et SQLite sans CGO).
Le client initie le WebSocket sur :443/wss. Votre hôte de base de données n'accepte jamais de connexions entrantes — aucun port à ouvrir, aucune entrée à configurer.
Une identification est liée à une seule base de données de schéma. Un nouvel appairage la fait tourner et évince instantanément la connexion active précédente.
Le jeton de rafraîchissement de 365 jours (stocké en mode 600) est échangé contre des jetons d'accès de 15 minutes qui authentifient le WebSocket. Une révocation dans l'interface déconnecte un client actif en ~1 seconde.
Exécutez le client avec un rôle de base de données dédié, limité au schéma synchronisé, afin qu'un jeton compromis ne puisse rien atteindre d'autre.
| Commande | Ce que cela fait |
|---|---|
| ee-database pair --server URL | Appairage par code d'appareil confirmé dans le navigateur. Choisissez la base de données à synchroniser. |
| ee-database pair --server URL <token> | Appairez avec un jeton émis sur la page Bases de données (compatible sans interface). |
| ee-database run --dsn DSN [--save-dsn] [--skip-bootstrap] | Amorcez à partir de l'instantané (sauf si ignoré), puis connectez-vous et appliquez les deltas. |
| ee-database run … --create-missing | Créez d'abord la base de données cible si elle n'existe pas, en utilisant les identifiants propres au DSN (postgres nécessite CREATEDB, mysql le privilège CREATE ; les fichiers sqlite sont de toute façon créés automatiquement). |
| ee-database run … --create-missing --admin-dsn DSN | Initialisez tout ce que désigne le DSN cible via une connexion admin : le rôle/utilisateur manquant (avec le mot de passe du DSN) et la base de données dont il est propriétaire. Le DSN cible n'a alors besoin d'aucun droit de création ; le DSN admin n'est jamais stocké. |
| ee-database run --all | Synchronisez toutes les bases de données appairées simultanément depuis un seul processus (chacune nécessite un DSN enregistré). |
| ee-database status | Affichez l'état de l'appairage, l'URL du serveur et les bases de données appairées. |
| ee-database disconnect | Oubliez les identifiants locaux d'un appairage. Révoquez côté serveur depuis l'interface. |
| ee-database version | Version imprimable. |
Les identifiants sont stockés en mode-600, un profil par base de données appairée, sous ~/.config/ee-database/profiles/ — appairez une fois par base de données, et --database NAME en sélectionne une lorsque plusieurs sont appairées. Vous préférez ne pas automatiser du tout ? Le même flux est disponible en REST simple : GET /api/databases//changes puis POST /api/databases//ack — voir Bases de données.
Le client est sous licence MIT et se trouve dans un dépôt public, afin que chacun puisse auditer exactement ce qui s'exécute sur sa base de données.
Source : github.com/TOT-Concept/ee-database
Versions : github.com/TOT-Concept/ee-database/releases — chaque binaire est signé avant publication.