;
};
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}
;
};
¿Prefieres no configurarlo manualmente? Pega un enlace a esta página en una sesión de Devin y pídele que lo configure todo por ti.
Analiza tus colecciones de MongoDB y diseña equivalentes relacionales. Si tus datos incluyen varias colecciones con relaciones, crea primero un Diagrama Entidad-Relación para validar las decisiones de normalización antes de escribir cualquier SQL.
Patrones clave de transformación:
* **Document IDs**: Convierte los campos `_id` de MongoDB en claves primarias de tipo UUID o SERIAL
* **Nested objects**: Descompón los objetos anidados en tablas independientes con relaciones de clave foránea
* **Arrays**: Usa tipos de array de Postgres o tablas de unión independientes
* **Embedded documents**: Extrae estos documentos a tablas relacionadas con una normalización adecuada
```txt Analyze MongoDB schema and design Postgres tables theme={null}
Analiza nuestras colecciones existentes de MongoDB y los esquemas de documentos.
Para cada colección:
1. Diseña una tabla equivalente en PostgreSQL con tipos de columna adecuados
2. Identifica las relaciones y crea claves foráneas
3. Descompón los objetos anidados en tablas independientes cuando corresponda
4. Crea un ERD que muestre todas las entidades y sus relaciones
5. Convierte los ObjectIds de MongoDB a UUIDs
6. Escribe la migración SQL para crear el esquema
```
Una vez que el esquema esté listo, configura la seguridad: crea roles de Postgres con privilegios adecuados y habilita las políticas de Row Level Security (RLS, seguridad a nivel de fila) en las tablas que necesiten control de acceso a nivel de fila.
Reemplaza tu driver de MongoDB (por ejemplo, `mongoose`, `mongodb`) por una librería cliente de Postgres — Prisma, Drizzle, TypeORM o `node-postgres` según tu stack. Actualiza la configuración de tu entorno con `DATABASE_URL` o credenciales de conexión equivalentes.
Patrones de migración de consultas:
* **Operaciones de búsqueda (find)** → consultas SQL `SELECT` o métodos del ORM `.findMany()` / `.select()`
* **Pipelines de agregación** → `JOIN`s, `GROUP BY`, subconsultas, funciones de ventana
* **Actualizaciones** → sentencias SQL `UPDATE`
* **Inserciones** → sentencias SQL `INSERT` o métodos de inserción masiva
```txt Migrate backend from MongoDB to Postgres theme={null}
Reemplaza nuestro driver de MongoDB por [Prisma / Drizzle / node-postgres].
Para cada módulo de backend:
1. Reemplaza las importaciones de MongoDB y la configuración de la conexión
2. Reescribe todas las consultas para usar el nuevo cliente de Postgres
3. Actualiza el manejo de errores (por ejemplo, las violaciones de restricciones de unicidad son el código 23505 de Postgres)
4. Conserva todos los formatos de respuesta de la API existentes
5. Ejecuta las pruebas después de cada módulo para verificar que nada falle
```
Si tu aplicación usa autenticación JWT personalizada con un repositorio de usuarios en MongoDB, actualiza las consultas de búsqueda de usuarios para usar Postgres manteniendo la misma lógica de generación y validación de tokens.
Actualiza los servicios de frontend para manejar cualquier cambio en la estructura de los datos derivado de la migración — lo más común es que `_id` pase a ser `id`. Mantén las firmas de los métodos de servicio existentes para que los componentes no necesiten cambios.
* Actualiza los servicios de autenticación si cambió el flujo de autenticación
* Ajusta el manejo de solicitudes y respuestas del cliente HTTP para las nuevas estructuras de datos
* Actualiza los route guards y resolvers si cambiaron los patrones de recuperación de datos
Exporta los datos de MongoDB, transfórmalos para que se ajusten al esquema de Postgres e impórtalos.
```txt Crea un script de migración de datos theme={null}
Escribe un script de migración que:
1. Exporte datos de nuestras colecciones de MongoDB
2. Transforme documentos para que se ajusten al esquema de PostgreSQL
(ObjectId → UUID, aplane los documentos incrustados, convierta fechas)
3. Importe en PostgreSQL preservando las relaciones de claves foráneas
4. Verifique la integridad de los datos: recuentos de filas, relaciones de claves, comprobaciones puntuales
```
Después de la importación, ejecuta la suite de pruebas completa contra el backend de Postgres. Verifica que todas las operaciones CRUD, los flujos de autenticación y el acceso basado en roles funcionen correctamente.
Implementa el despliegue con feature flags para un lanzamiento gradual. Mantén la instancia de MongoDB como respaldo durante la transición.
Lista de comprobación posterior al despliegue:
* Agrega índices para las columnas consultadas con frecuencia
* Usa `EXPLAIN ANALYZE` para identificar consultas lentas
* Configura el pool de conexiones (por ejemplo, PgBouncer)
* Supervisa el rendimiento de las consultas y la utilización de las conexiones
* Documenta los procedimientos de reversión ante problemas críticos
```txt Post-migration optimization theme={null}
The MongoDB to Postgres migration is deployed. Run EXPLAIN ANALYZE
on our most frequent queries and suggest indexes. Check for:
1. Sequential scans on large tables that should use indexes
2. Missing indexes on foreign key columns
3. Queries that could benefit from partial or composite indexes
4. Connection pool sizing recommendations based on our workload
```
Una vez que todo esté estable y verificado, retira la instancia de MongoDB.
Si necesitas ejecutar este patrón de migración en múltiples servicios o repositorios, guárdalo como un [playbook](/es/product-guides/creating-playbooks) para que cada sesión siga el mismo proceso. A continuación se muestra un ejemplo de playbook para una migración de MongoDB a Postgres:
```txt MongoDB to PostgreSQL Migration theme={null}
## Descripción general
Migrar un proyecto de MongoDB a PostgreSQL. Esto abarca el diseño
del esquema, la migración de la API de backend, las actualizaciones
de la capa de servicio del frontend, la migración de datos y el despliegue.
## Lo que se necesita del usuario
- Acceso a la base de datos MongoDB de origen (cadena de conexión o exportación)
- Credenciales de la base de datos PostgreSQL de destino
(host, puerto, base de datos, usuario, contraseña)
- Descripción del modelo de datos de la aplicación y las consultas clave
- Cualquier requisito de autenticación/autorización para el nuevo sistema
## Fase 1: Diseño y configuración del esquema de base de datos
### Paso 1: Configuración del proyecto
1. Aprovisionar una base de datos PostgreSQL y registrar las credenciales de conexión
2. Analizar las colecciones de MongoDB existentes y los esquemas de documentos
3. Diseñar las tablas equivalentes en PostgreSQL con las relaciones adecuadas
### Paso 2: Creación del ERD
Si el esquema de MongoDB de origen involucra múltiples colecciones con
relaciones (documentos embebidos, referencias mediante ObjectIds o
patrones de tablas de unión), crear un Diagrama Entidad-Relación antes
de diseñar las tablas de PostgreSQL:
1. Identificar todas las entidades y sus atributos a partir de las
colecciones de MongoDB
2. Mapear las relaciones entre entidades
(uno a uno, uno a muchos, muchos a muchos)
3. Generar un ERD con una herramienta como dbdiagram.io, Mermaid o
draw.io
4. Usar el ERD para validar las decisiones de normalización y el diseño
de claves foráneas antes de escribir cualquier SQL
Omitir este paso si la migración involucra solo una única colección
o un conjunto reducido de colecciones independientes sin relaciones
significativas.
### Paso 3: Patrones de traducción de esquemas
- IDs de documentos: Convertir los campos _id de MongoDB a claves primarias
UUID o SERIAL de PostgreSQL
- Objetos anidados: Aplanar en tablas separadas con relaciones de clave foránea
- Arrays: Usar tipos de array de PostgreSQL o tablas de unión separadas
- Documentos embebidos: Extraer en tablas relacionadas con la normalización adecuada
### Paso 4: Configuración de seguridad
1. Crear roles y usuarios de PostgreSQL con los privilegios adecuados
(solo lectura, lectura-escritura, administrador)
2. Usar GRANT/REVOKE para restringir el acceso a tablas y columnas por rol
3. Si la aplicación requiere control de acceso a nivel de fila, habilitar
políticas de Row Level Security (RLS) en las tablas correspondientes
### Paso 5: Funciones y disparadores de base de datos
1. Crear disparadores de gestión de usuarios para la creación automática
de registros (p. ej., marcas de tiempo de auditoría, valores predeterminados)
2. Implementar funciones de lógica de negocio en PL/pgSQL para reemplazar
las validaciones a nivel de aplicación donde corresponda
## Fase 2: Migración de la API de backend
### Paso 1: Gestión de dependencias
1. Reemplazar los controladores de MongoDB (p. ej., mongodb, mongoose) por una
biblioteca cliente de PostgreSQL (p. ej., pg para Node.js, psycopg2
para Python, o un ORM como Prisma/Sequelize/TypeORM)
2. Actualizar la configuración del entorno con las credenciales de conexión
de PostgreSQL (DATABASE_URL o variables individuales de host/puerto/db/usuario/
contraseña)
3. Eliminar o reemplazar cualquier middleware o utilidad específica de MongoDB
### Paso 2: Actualizaciones del sistema de autenticación
1. Si la aplicación existente usa autenticación JWT personalizada, conservarla
y actualizar las consultas de búsqueda de usuarios para usar PostgreSQL
2. Si se migra a un nuevo sistema de autenticación, reemplazar el middleware
de generación y validación de tokens según corresponda
3. Mantener los formatos de respuesta de la API existentes para garantizar
la compatibilidad con el frontend
### Paso 3: Patrones de migración de consultas
- Operaciones de búsqueda: Convertir collection.find() a consultas SQL SELECT
(o equivalentes de ORM como .findMany(), .select())
- Pipelines de agregación: Reemplazar con JOINs, GROUP BY,
subconsultas y funciones de ventana de PostgreSQL
- Actualizaciones: Convertir updateOne/updateMany a sentencias SQL UPDATE
- Inserciones: Reemplazar insertOne/insertMany con sentencias SQL INSERT
o métodos de inserción masiva
### Paso 4: Actualizaciones del manejo de errores
1. Reemplazar los códigos de error específicos de MongoDB con el manejo
de errores de PostgreSQL (p. ej., las violaciones de restricción de unicidad corresponden al código 23505)
2. Mantener formatos de respuesta de error consistentes para los servicios
del frontend
## Fase 3: Actualizaciones de la capa de servicio del frontend
### Paso 1: Migración del servicio de autenticación
1. Actualizar el servicio de autenticación de usuarios para que funcione
con los nuevos endpoints de autenticación del backend
2. Si el enfoque de autenticación cambió, actualizar los flujos de
inicio/cierre de sesión y la gestión de tokens según corresponda
3. Modificar la creación de objetos de usuario para que funcione con el
nuevo formato de datos de usuario de PostgreSQL
### Paso 2: Actualizaciones del cliente HTTP
1. Actualizar las URLs de los endpoints de la API si la estructura del backend cambia
2. Ajustar el manejo de solicitudes/respuestas si las estructuras de datos cambiaron
(p. ej., _id pasando a ser id)
3. Mantener las firmas de los métodos de servicio existentes para garantizar
la compatibilidad con los componentes
### Paso 3: Actualizaciones de guardias de ruta y resolvers
1. Actualizar los guardias de autenticación para que funcionen con el nuevo sistema de autenticación
2. Modificar los resolvers de ruta si los patrones de obtención de datos cambiaron
3. Verificar que los flujos de datos de los componentes existentes permanezcan intactos
## Fase 4: Migración de datos y pruebas
### Paso 1: Exportación y transformación de datos
1. Exportar las colecciones de MongoDB usando mongoexport o scripts personalizados
2. Transformar los datos para que coincidan con los requisitos del esquema de PostgreSQL
3. Gestionar las conversiones de tipos de datos (ObjectId a UUID, fechas,
documentos embebidos a claves foráneas, etc.)
### Paso 2: Proceso de importación de datos
1. Importar datos usando psql \copy, pg_restore o scripts de migración personalizados
2. Verificar las relaciones de claves foráneas y las restricciones después de la importación
3. Ejecutar conteos y verificaciones puntuales para confirmar la integridad
y completitud de los datos
### Paso 3: Pruebas de extremo a extremo
1. Probar todas las operaciones CRUD con datos reales
2. Verificar que los flujos de autenticación funcionen correctamente
3. Probar la funcionalidad de administración y el acceso basado en roles
## Fase 5: Despliegue y monitoreo
### Paso 1: Estrategia de despliegue
1. Desplegar los cambios del backend con indicadores de funcionalidad para un lanzamiento gradual
2. Actualizar la configuración del frontend para los endpoints de producción
respaldados por PostgreSQL
3. Implementar agrupación de conexiones de base de datos (p. ej., PgBouncer) y monitoreo
### Paso 2: Optimización del rendimiento
1. Agregar índices de base de datos para las columnas consultadas con frecuencia
2. Usar EXPLAIN ANALYZE para identificar y optimizar las consultas lentas
3. Monitorear el rendimiento de las consultas y el uso del pool de conexiones
### Paso 3: Planificación de reversión
1. Mantener la instancia de MongoDB como respaldo durante el período de transición
2. Documentar los procedimientos de reversión para problemas críticos
3. Crear scripts de sincronización de datos si es necesario
## Patrones clave de migración
### Migración de autenticación
- Desde: JWT personalizado con almacén de usuarios en MongoDB
- Hacia: JWT personalizado (o autenticación de framework) con almacén de usuarios en PostgreSQL
- Conservar: Interfaces de objetos de usuario existentes y contratos
de componentes
### Migración de consultas de base de datos
- Desde: Pipelines de agregación de MongoDB y consultas de documentos
- Hacia: Consultas SQL con JOINs, GROUP BY y funciones de ventana
- Conservar: Formatos de respuesta de la API y estructuras de datos
### Migración de seguridad
- Desde: Autorización a nivel de aplicación con MongoDB
- Hacia: Roles/privilegios de PostgreSQL más políticas RLS opcionales
- Conservar: Lógica de roles y permisos de usuario
## Especificaciones
- Todos los contratos de API existentes y los formatos de respuesta deben
conservarse
- La integridad de los datos debe verificarse tras la migración (conteos
de filas, relaciones clave, verificaciones puntuales)
- La instancia de MongoDB debe permanecer disponible como alternativa de
respaldo durante el período de transición
- Validación: Ejecutar el conjunto de pruebas de la aplicación de extremo a extremo
contra el backend de PostgreSQL y confirmar que todas las pruebas pasen
```