;
};
export const PromptBlock = ({children, type, agent, intent, playbookId}) => {
var utm = 'utm_source=docs&utm_medium=use-case-gallery&utm_campaign=prompt-block';
var tag = 'docs-use-case-gallery';
var agentParams = (agent ? '&agent=' + agent : '') + (intent ? '&intent=' + intent : '') + (playbookId ? '&playbookId=' + playbookId : '');
var label = type === 'schedule' ? 'Schedule in Devin' : type === 'playbook' ? 'Create Playbook' : type === 'knowledge' ? 'Add to Knowledge' : agent === 'advanced' ? 'Try in Devin' : agent === 'dana' ? 'Try in Dana' : agent === 'ada' ? 'Try in Ask Devin' : 'Try in Devin';
var buildUrl = function (text) {
var encoded = encodeURIComponent(text);
if (type === 'schedule') return 'https://app.devin.ai/settings/schedules/create?' + utm + agentParams + '&prompt=' + encoded;
if (type === 'playbook') return 'https://app.devin.ai/settings/playbooks/create?' + utm + '&body=' + encoded;
if (type === 'knowledge') return 'https://app.devin.ai/knowledge?' + utm + '&body=' + encoded;
if (agent === 'ada') return 'https://app.devin.ai/search?' + utm + '&noSubmit=true&prompt=' + encoded;
return 'https://app.devin.ai/?tags=' + tag + '&' + utm + agentParams + '&prompt=' + encoded;
};
const ref = React.useRef(null);
const [href, setHref] = React.useState('#');
React.useEffect(() => {
if (!ref.current) return;
var codeEl = ref.current.querySelector('pre code');
if (codeEl) {
var text = codeEl.textContent.trim();
if (text) setHref(buildUrl(text));
}
var header = ref.current.querySelector('[data-component-part="code-block-header"]');
if (header && !header.querySelector('.prompt-block-devin-link')) {
var link = document.createElement('a');
link.href = href;
link.target = '_blank';
link.rel = 'noopener noreferrer';
link.className = 'prompt-block-devin-link';
link.style.cssText = 'display:inline-flex;align-items:center;gap:6px;text-decoration:none;color:#fff;font-size:11px;font-weight:500;padding:4px 10px;border-radius:6px;white-space:nowrap;background:#317CFF;transition:background 0.2s;margin-left:8px;';
link.innerHTML = ' ' + label;
link.onmouseenter = function () {
link.style.background = '#2968D9';
};
link.onmouseleave = function () {
link.style.background = '#317CFF';
};
header.appendChild(link);
}
var existingLink = ref.current.querySelector('.prompt-block-devin-link');
if (existingLink && href !== '#') existingLink.href = href;
});
return
{children}
;
};
Vous ne souhaitez pas effectuer cette configuration manuellement ? Collez un lien vers cette page dans une session Devin et demandez-lui de tout configurer pour vous.
Analysez vos collections MongoDB et concevez des équivalents relationnels. Si vos données impliquent plusieurs collections avec des relations, créez d’abord un diagramme entité-relation pour valider les décisions de normalisation avant d’écrire du SQL.
Principaux modèles de conversion :
* **Document IDs** : convertissez les champs `_id` de MongoDB en clés primaires UUID ou SERIAL
* **Objets imbriqués** : aplatissez-les dans des tables distinctes avec des relations de clé étrangère
* **Tableaux** : utilisez les types de tableaux Postgres ou des tables de jonction distinctes
* **Documents intégrés** : extrayez-les dans des tables liées avec une normalisation appropriée
```txt Analyze MongoDB schema and design Postgres tables theme={null}
Analyze our existing MongoDB collections and document schemas.
For each collection:
1. Design a PostgreSQL table equivalent with proper column types
2. Identify relationships and create foreign keys
3. Flatten nested objects into separate tables where appropriate
4. Create an ERD showing all entities and relationships
5. Convert MongoDB ObjectIds to UUIDs
6. Write the SQL migration to create the schema
```
Une fois le schéma prêt, configurez la sécurité : créez des rôles Postgres avec les privilèges appropriés et activez les stratégies de sécurité au niveau des lignes (Row Level Security, RLS) sur les tables qui nécessitent un contrôle d’accès au niveau des lignes.
Remplacez votre driver MongoDB (par exemple `mongoose`, `mongodb`) par une bibliothèque cliente Postgres — Prisma, Drizzle, TypeORM ou `node-postgres` selon votre stack. Mettez à jour votre configuration d’environnement avec `DATABASE_URL` ou des identifiants de connexion équivalents.
Modèles de migration de requêtes :
* **Opérations de recherche (find)** → requêtes SQL `SELECT` ou méthodes ORM `.findMany()` / `.select()`
* **Pipelines d’agrégation** → `JOIN`, `GROUP BY`, sous‑requêtes, fonctions de fenêtrage
* **Mises à jour** → instructions SQL `UPDATE`
* **Insertions** → instructions SQL `INSERT` ou méthodes d’insertion en masse
```txt Migrate backend from MongoDB to Postgres theme={null}
Remplacez notre driver MongoDB par [Prisma / Drizzle / node-postgres].
Pour chaque module backend :
1. Remplacez les imports MongoDB et la configuration de connexion
2. Réécrivez toutes les requêtes pour utiliser le nouveau client Postgres
3. Mettez à jour la gestion des erreurs (par exemple, les violations de contrainte d’unicité utilisent le code Postgres 23505)
4. Préservez tous les formats de réponse d’API existants
5. Lancez les tests après chaque module pour vérifier que rien ne casse
```
Si votre application utilise une authentification JWT personnalisée avec un stockage des utilisateurs MongoDB, mettez à jour les requêtes de recherche d’utilisateurs pour utiliser Postgres tout en conservant la même logique de génération et de validation de jetons.
Mettez à jour les services frontend pour gérer toute modification de structure de données due à la migration — le cas le plus courant étant la transformation de `_id` en `id`. Conservez les signatures de méthodes de service existantes afin qu'il ne soit pas nécessaire de modifier les composants.
* Mettez à jour les services d'authentification si le flux d'authentification a changé
* Adaptez la gestion des requêtes/réponses du client HTTP aux nouvelles structures de données
* Mettez à jour les gardes de route et les résolveurs si les modèles de récupération de données ont changé
Exportez vos données MongoDB, transformez-les pour les adapter au schéma PostgreSQL, puis importez-les.
```txt Créer un script de migration de données theme={null}
Rédigez un script de migration qui :
1. Exporte les données de nos collections MongoDB
2. Transforme les documents pour les adapter au schéma PostgreSQL
(ObjectId → UUID, aplatir les documents imbriqués, convertir les dates)
3. Importe les données dans PostgreSQL en préservant les relations de clés étrangères
4. Vérifie l'intégrité des données : nombre de lignes, relations entre clés, vérifications ponctuelles
```
Après l'import, exécutez l'intégralité de la suite de tests sur le backend PostgreSQL. Vérifiez que toutes les opérations CRUD, les flux d'authentification et le contrôle d'accès fondé sur les rôles fonctionnent correctement.
Déployez avec des feature flags pour un déploiement progressif. Conservez l’instance MongoDB comme solution de secours pendant la transition.
Liste de contrôle post-déploiement :
* Ajoutez des index pour les colonnes fréquemment interrogées
* Utilisez `EXPLAIN ANALYZE` pour identifier les requêtes lentes
* Configurez un pool de connexions (par exemple PgBouncer)
* Surveillez les performances des requêtes et l’utilisation des connexions
* Documentez les procédures de rollback pour les problèmes critiques
```txt Optimisation post-migration theme={null}
La migration de MongoDB vers Postgres est en production. Exécutez EXPLAIN ANALYZE
sur nos requêtes les plus courantes et proposez des index. Vérifiez :
1. Les scans séquentiels sur les grandes tables qui devraient utiliser des index
2. Les index manquants sur les colonnes de clé étrangère
3. Les requêtes qui pourraient bénéficier d’index partiels ou composites
4. Les recommandations de dimensionnement du pool de connexions en fonction de notre charge de travail
```
Une fois que tout est stable et vérifié, mettez l’instance MongoDB hors service.
Si vous devez appliquer ce schéma de migration à plusieurs services ou dépôts, enregistrez-le en tant que [playbook](/fr/product-guides/creating-playbooks) afin que chaque session suive le même processus. Voici un exemple de playbook pour une migration de MongoDB vers Postgres :
```txt MongoDB to PostgreSQL Migration theme={null}
## Vue d'ensemble
Migrer un projet de MongoDB vers PostgreSQL. Cela couvre la conception
du schéma, la migration de l'API backend, les mises à jour de la couche
de service frontend, la migration des données et le déploiement.
## Ce dont on a besoin de l'utilisateur
- Accès à la base de données MongoDB source (chaîne de connexion ou export)
- Identifiants de la base de données PostgreSQL cible
(hôte, port, base de données, utilisateur, mot de passe)
- Description du modèle de données de l'application et des requêtes clés
- Toute exigence d'authentification/autorisation pour le nouveau système
## Phase 1 : Conception et configuration du schéma de base de données
### Étape 1 : Configuration du projet
1. Provisionner une base de données PostgreSQL et noter les identifiants de connexion
2. Analyser les collections MongoDB existantes et les schémas de documents
3. Concevoir les équivalents de tables PostgreSQL avec les relations appropriées
### Étape 2 : Création du diagramme entité-relation (ERD)
Si le schéma MongoDB source implique plusieurs collections avec
des relations (documents imbriqués, références via ObjectIds ou
patterns de tables de jonction), créer un diagramme entité-relation avant
de concevoir les tables PostgreSQL :
1. Identifier toutes les entités et leurs attributs à partir des
collections MongoDB
2. Cartographier les relations entre les entités
(un-à-un, un-à-plusieurs, plusieurs-à-plusieurs)
3. Produire un ERD à l'aide d'un outil tel que dbdiagram.io, Mermaid ou
draw.io
4. Utiliser l'ERD pour valider les décisions de normalisation et la conception
des clés étrangères avant d'écrire du SQL
Passer cette étape si la migration ne concerne qu'une seule collection
ou quelques collections indépendantes sans relations significatives.
### Étape 3 : Modèles de traduction de schéma
- Identifiants de documents : Convertir les champs MongoDB _id en clés primaires
UUID ou SERIAL PostgreSQL
- Objets imbriqués : Aplatir en tables séparées avec des relations de clés étrangères
- Tableaux : Utiliser les types de tableaux PostgreSQL ou des tables de jonction séparées
- Documents imbriqués : Extraire dans des tables liées avec une normalisation appropriée
### Étape 4 : Configuration de la sécurité
1. Créer des rôles et des utilisateurs PostgreSQL avec les privilèges appropriés
(lecture seule, lecture-écriture, admin)
2. Utiliser GRANT/REVOKE pour restreindre l'accès aux tables et colonnes par rôle
3. Si l'application nécessite un contrôle d'accès au niveau des lignes, activer les
politiques de sécurité au niveau des lignes (RLS) sur les tables concernées
### Étape 5 : Fonctions et déclencheurs de base de données
1. Créer des déclencheurs de gestion des utilisateurs pour la création automatique
d'enregistrements (ex. : horodatages d'audit, valeurs par défaut)
2. Implémenter des fonctions de logique métier en PL/pgSQL pour remplacer
les validations au niveau de l'application le cas échéant
## Phase 2 : Migration de l'API backend
### Étape 1 : Gestion des dépendances
1. Remplacer les pilotes MongoDB (ex. : mongodb, mongoose) par une
bibliothèque cliente PostgreSQL (ex. : pg pour Node.js, psycopg2
pour Python, ou un ORM comme Prisma/Sequelize/TypeORM)
2. Mettre à jour la configuration de l'environnement avec les identifiants
de connexion PostgreSQL (DATABASE_URL ou variables individuelles hôte/port/db/
utilisateur/mot de passe)
3. Supprimer ou remplacer tout middleware ou utilitaire spécifique à MongoDB
### Étape 2 : Mises à jour du système d'authentification
1. Si l'application existante utilise une authentification JWT personnalisée,
la conserver et mettre à jour les requêtes de recherche d'utilisateurs pour
utiliser PostgreSQL
2. Si migration vers un nouveau système d'authentification, remplacer la génération
de jetons et le middleware de validation en conséquence
3. Maintenir les formats de réponse API existants pour la compatibilité frontend
### Étape 3 : Modèles de migration des requêtes
- Opérations de recherche : Convertir collection.find() en requêtes SQL SELECT
(ou équivalents ORM comme .findMany(), .select())
- Pipelines d'agrégation : Remplacer par des JOIN PostgreSQL, GROUP BY,
sous-requêtes et fonctions de fenêtrage
- Mises à jour : Convertir updateOne/updateMany en instructions SQL UPDATE
- Insertions : Remplacer insertOne/insertMany par des instructions SQL INSERT
ou des méthodes d'insertion en masse
### Étape 4 : Mises à jour de la gestion des erreurs
1. Remplacer les codes d'erreur spécifiques à MongoDB par la gestion des erreurs
PostgreSQL (ex. : les violations de contrainte unique ont le code 23505)
2. Maintenir des formats de réponse d'erreur cohérents pour les services frontend
## Phase 3 : Mises à jour de la couche de service frontend
### Étape 1 : Migration du service d'authentification
1. Mettre à jour le service d'authentification des utilisateurs pour fonctionner
avec les nouveaux points de terminaison d'authentification backend
2. Si l'approche d'authentification a changé, mettre à jour les flux de
connexion/déconnexion et la gestion des jetons en conséquence
3. Modifier la création d'objets utilisateur pour fonctionner avec le nouveau
format de données utilisateur de PostgreSQL
### Étape 2 : Mises à jour du client HTTP
1. Mettre à jour les URL des points de terminaison API si la structure backend change
2. Ajuster la gestion des requêtes/réponses si les formes des données ont changé
(ex. : _id devenant id)
3. Maintenir les signatures de méthodes de service existantes pour la compatibilité
des composants
### Étape 3 : Mises à jour des gardes de route et des résolveurs
1. Mettre à jour les gardes d'authentification pour fonctionner avec le nouveau
système d'authentification
2. Modifier les résolveurs de route si les modèles de récupération de données ont changé
3. Tester que les flux de données des composants existants restent intacts
## Phase 4 : Migration des données et tests
### Étape 1 : Export et transformation des données
1. Exporter les collections MongoDB à l'aide de mongoexport ou de scripts personnalisés
2. Transformer les données pour correspondre aux exigences du schéma PostgreSQL
3. Gérer les conversions de types de données (ObjectId vers UUID, dates,
documents imbriqués vers clés étrangères, etc.)
### Étape 2 : Processus d'importation des données
1. Importer les données à l'aide de psql \copy, pg_restore ou de scripts de migration
personnalisés
2. Vérifier les relations de clés étrangères et les contraintes après l'importation
3. Effectuer des comptages et des vérifications ponctuelles pour confirmer l'intégrité
et l'exhaustivité des données
### Étape 3 : Tests de bout en bout
1. Tester toutes les opérations CRUD avec des données réelles
2. Vérifier que les flux d'authentification fonctionnent correctement
3. Tester les fonctionnalités d'administration et l'accès basé sur les rôles
## Phase 5 : Déploiement et surveillance
### Étape 1 : Stratégie de déploiement
1. Déployer les modifications backend avec des indicateurs de fonctionnalité pour
un déploiement progressif
2. Mettre à jour la configuration frontend pour les points de terminaison de
production basés sur PostgreSQL
3. Implémenter le regroupement de connexions à la base de données (ex. : PgBouncer)
et la surveillance
### Étape 2 : Optimisation des performances
1. Ajouter des index de base de données pour les colonnes fréquemment interrogées
2. Utiliser EXPLAIN ANALYZE pour identifier et optimiser les requêtes lentes
3. Surveiller les performances des requêtes et l'utilisation du pool de connexions
### Étape 3 : Planification du retour arrière
1. Maintenir l'instance MongoDB comme sauvegarde pendant la période de transition
2. Documenter les procédures de retour arrière pour les problèmes critiques
3. Créer des scripts de synchronisation des données si nécessaire
## Principaux modèles de migration
### Migration de l'authentification
- De : JWT personnalisé avec stockage des utilisateurs MongoDB
- Vers : JWT personnalisé (ou authentification de framework) avec stockage
des utilisateurs PostgreSQL
- Conserver : Les interfaces d'objets utilisateur existantes et les contrats
de composants
### Migration des requêtes de base de données
- De : Pipelines d'agrégation MongoDB et requêtes de documents
- Vers : Requêtes SQL avec JOIN, GROUP BY et fonctions de fenêtrage
- Conserver : Les formats de réponse API et les structures de données
### Migration de la sécurité
- De : Autorisation au niveau de l'application avec MongoDB
- Vers : Rôles/privilèges PostgreSQL plus politiques RLS optionnelles
- Conserver : La logique de rôle et de permission des utilisateurs
## Spécifications
- Tous les contrats API existants et les formats de réponse doivent être
préservés
- L'intégrité des données doit être vérifiée après la migration (comptages
des lignes, relations clés, vérifications ponctuelles)
- L'instance MongoDB doit rester disponible comme solution de repli pendant
la période de transition
- Validation : Exécuter la suite de tests de l'application de bout en bout
contre le backend PostgreSQL et confirmer que tous les tests réussissent
```