Loading documentation...
Preparing Ring content
Conceptos, valor y escenarios típicos de clon — menos código.
Conceptos, valor y escenarios típicos de clon — menos código.
Preparing Ring content
Preparing Ring content
Preparing Ring content
Ring guarda su esquema PostgreSQL en dos lugares dentro de ring/web/data/. schema.sql es la fuente única de verdad aplanada para bases de datos nuevas. migrations/ contiene los archivos incrementales numerados que llevaron a las bases de datos existentes a la misma forma. Esta página explica cuál usar y cuándo.
Usa las pestañas Fundador / Desarrollador de la barra lateral para filtrar esta página. Las secciones compartidas se aplican a ambos públicos.
Estado: ./install.sh setup-db y npm run db:apply-schema fallan actualmente en los checkouts públicos porque buscan rutas que se movieron a web/. Además, schema.sql contiene CREATE EXTENSION IF NOT EXISTS postgis;, así que un psql -f data/schema.sql sin más se detiene con un error en las imágenes de PostgreSQL que no incluyen PostGIS (por ejemplo postgres:16-alpine). Usa los comandos del paso 2 más abajo.
| La documentación anterior decía | Comportamiento actual |
|---|---|
Aplica schema.sql y después 002, 003, 004 en orden | Las instalaciones nuevas aplican solo web/data/schema.sql (aplanado, versión 4.1.0) |
Ejecuta ./scripts/run-migration.sh o apply-*-migrations-dev.sh | Esos scripts no están en el árbol público. Usa psql directamente |
Instala postgresql@18 de Homebrew con un script de arranque | Sirve cualquier PostgreSQL 16 o posterior. El script de arranque es interno de Ringdom |
Carga las noticias desde scripts/seed-news-v1.6.0.sql | Ese archivo no existe. Los datos iniciales de monedas, países, ajustes de tienda y categorías de noticias están dentro de schema.sql |
data/schema-delta.sql | No se usa. Los cambios viven como archivos numerados en data/migrations/ |
No necesitas saber SQL para gestionar un clon de Ring, pero sí conviene que conozcas la regla que sigue tu desarrollador: una base de datos nueva recibe un solo archivo, una base de datos existente recibe solo los archivos nuevos. Esa regla es la que mantiene las actualizaciones aburridas.
Un solo archivo de esquema crea todas las tablas (109 en la versión 4.1.0) más los datos de referencia. Sin repetir el historial.
Tu desarrollador aplica, después de una copia de seguridad, solo los archivos numerados que tu base de datos aún no ha visto.
PostgreSQL es el backend de producción predeterminado (k8s-postgres-fcm).
Siguiente paso: ejecuta la app contra la base de datos que acabas de crear.
Mismo flujo: aplica el esquema al contenedor de Postgres de compose.
Requisito previo: por qué k8s-postgres-fcm necesita este esquema.
Ver también: install.sh y los scripts npm de base de datos, incluidos los que fallan hoy.
Ring guarda su esquema PostgreSQL en dos lugares dentro de ring/web/data/. schema.sql es la fuente única de verdad aplanada para bases de datos nuevas. migrations/ contiene los archivos incrementales numerados que llevaron a las bases de datos existentes a la misma forma. Esta página explica cuál usar y cuándo.
Usa las pestañas Fundador / Desarrollador de la barra lateral para filtrar esta página. Las secciones compartidas se aplican a ambos públicos.
Estado: ./install.sh setup-db y npm run db:apply-schema fallan actualmente en los checkouts públicos porque buscan rutas que se movieron a web/. Además, schema.sql contiene CREATE EXTENSION IF NOT EXISTS postgis;, así que un psql -f data/schema.sql sin más se detiene con un error en las imágenes de PostgreSQL que no incluyen PostGIS (por ejemplo postgres:16-alpine). Usa los comandos del paso 2 más abajo.
| La documentación anterior decía | Comportamiento actual |
|---|---|
Aplica schema.sql y después 002, 003, 004 en orden | Las instalaciones nuevas aplican solo web/data/schema.sql (aplanado, versión 4.1.0) |
Ejecuta ./scripts/run-migration.sh o apply-*-migrations-dev.sh | Esos scripts no están en el árbol público. Usa psql directamente |
Instala postgresql@18 de Homebrew con un script de arranque | Sirve cualquier PostgreSQL 16 o posterior. El script de arranque es interno de Ringdom |
Carga las noticias desde scripts/seed-news-v1.6.0.sql | Ese archivo no existe. Los datos iniciales de monedas, países, ajustes de tienda y categorías de noticias están dentro de schema.sql |
data/schema-delta.sql | No se usa. Los cambios viven como archivos numerados en data/migrations/ |
No necesitas saber SQL para gestionar un clon de Ring, pero sí conviene que conozcas la regla que sigue tu desarrollador: una base de datos nueva recibe un solo archivo, una base de datos existente recibe solo los archivos nuevos. Esa regla es la que mantiene las actualizaciones aburridas.
Un solo archivo de esquema crea todas las tablas (109 en la versión 4.1.0) más los datos de referencia. Sin repetir el historial.
Tu desarrollador aplica, después de una copia de seguridad, solo los archivos numerados que tu base de datos aún no ha visto.
PostgreSQL es el backend de producción predeterminado (k8s-postgres-fcm).
Siguiente paso: ejecuta la app contra la base de datos que acabas de crear.
Mismo flujo: aplica el esquema al contenedor de Postgres de compose.
Requisito previo: por qué k8s-postgres-fcm necesita este esquema.
Ver también: install.sh y los scripts npm de base de datos, incluidos los que fallan hoy.
Ring guarda su esquema PostgreSQL en dos lugares dentro de ring/web/data/. schema.sql es la fuente única de verdad aplanada para bases de datos nuevas. migrations/ contiene los archivos incrementales numerados que llevaron a las bases de datos existentes a la misma forma. Esta página explica cuál usar y cuándo.
Usa las pestañas Fundador / Desarrollador de la barra lateral para filtrar esta página. Las secciones compartidas se aplican a ambos públicos.
Estado: ./install.sh setup-db y npm run db:apply-schema fallan actualmente en los checkouts públicos porque buscan rutas que se movieron a web/. Además, schema.sql contiene CREATE EXTENSION IF NOT EXISTS postgis;, así que un psql -f data/schema.sql sin más se detiene con un error en las imágenes de PostgreSQL que no incluyen PostGIS (por ejemplo postgres:16-alpine). Usa los comandos del paso 2 más abajo.
| La documentación anterior decía | Comportamiento actual |
|---|---|
Aplica schema.sql y después 002, 003, 004 en orden | Las instalaciones nuevas aplican solo web/data/schema.sql (aplanado, versión 4.1.0) |
Ejecuta ./scripts/run-migration.sh o apply-*-migrations-dev.sh | Esos scripts no están en el árbol público. Usa psql directamente |
Instala postgresql@18 de Homebrew con un script de arranque | Sirve cualquier PostgreSQL 16 o posterior. El script de arranque es interno de Ringdom |
Carga las noticias desde scripts/seed-news-v1.6.0.sql | Ese archivo no existe. Los datos iniciales de monedas, países, ajustes de tienda y categorías de noticias están dentro de schema.sql |
data/schema-delta.sql | No se usa. Los cambios viven como archivos numerados en data/migrations/ |
No necesitas saber SQL para gestionar un clon de Ring, pero sí conviene que conozcas la regla que sigue tu desarrollador: una base de datos nueva recibe un solo archivo, una base de datos existente recibe solo los archivos nuevos. Esa regla es la que mantiene las actualizaciones aburridas.
Un solo archivo de esquema crea todas las tablas (109 en la versión 4.1.0) más los datos de referencia. Sin repetir el historial.
Tu desarrollador aplica, después de una copia de seguridad, solo los archivos numerados que tu base de datos aún no ha visto.
PostgreSQL es el backend de producción predeterminado (k8s-postgres-fcm).
Siguiente paso: ejecuta la app contra la base de datos que acabas de crear.
Mismo flujo: aplica el esquema al contenedor de Postgres de compose.
Requisito previo: por qué k8s-postgres-fcm necesita este esquema.
Ver también: install.sh y los scripts npm de base de datos, incluidos los que fallan hoy.
schema.sql. El sitio queda listo para el primer inicio de sesión del administrador.051_likes_uci_favorites_indexes.sql. Tu desarrollador hace una copia de seguridad, aplica ese único archivo y vuelve a desplegar.051 y posteriores pueden incluir un archivo .down.sql correspondiente para revertir el cambio. Los archivos anteriores no lo tienen.DB_HOSTDB_PORTDB_NAMEDB_USERDB_PASSWORDDB_SSLDATABASE_URLEjecuta el siguiente paso como superusuario o como propietario de la base de datos, porque schema.sql crea extensiones.
Si tu servidor tiene PostGIS instalado (por ejemplo una imagen postgis/postgis), aplica el archivo tal cual:
En PostgreSQL sin PostGIS, elimina antes la línea de PostGIS. Ninguna tabla usa un tipo de PostGIS, así que no cambia nada más:
Da acceso al esquema public al rol de tu app (DB_USER) y después inicia la app.
Aplica solo los archivos que tu base de datos no ha visto. Algunas migraciones se registran en schema_versions con un INSERT ... WHERE NOT EXISTS (016 a 025, 037, 043 a 046, 050, 051). Las demás no, así que antes de aplicarlas comprueba si existen las tablas o índices que crean.
Para revertir una migración que incluye un archivo down, aplica 051_likes_uci_favorites_indexes.down.sql de la misma forma. También borra su fila de schema_versions.
Usa el siguiente número libre después del archivo más alto de data/migrations/. Hazlo idempotente (IF NOT EXISTS), regístralo en schema_versions y añade un .down.sql cuando el cambio sea reversible.
Esto ejecuta ring/scripts/flatten-schema-from-migrations.sh. Necesita un PostgreSQL local donde tu rol pueda crear bases de datos (PGHOST y PGUSER toman por defecto localhost y ring_user). Recrea una base de datos temporal ring_schema_flatten, guarda una copia de schema.sql como schema.sql.bak-pre-flatten-<timestamp>, aplica el esquema anterior más todas las migraciones excepto 001, vuelca el DDL más los datos de referencia y verifica el resultado en ring_schema_flatten_verify. El paso de verificación necesita PostGIS por el motivo indicado arriba.
No. El aplanado solo reescribe el archivo schema.sql del repositorio. Nunca toca las bases de datos en producción.
schema.sql antiguo. ¿Qué archivos necesito?Compara SELECT version FROM schema_versions con los archivos numerados y después aplica en orden los que falten, tras una copia de seguridad. Solo algunos archivos registran una versión (consulta Base de datos existente más arriba), así que en caso de duda comprueba sus tablas. Ten en cuenta que una instalación nueva con el schema.sql de hoy muestra versiones hasta 045, aunque las tablas e índices de 046 a 051 ya estén presentes.
CREATE EXTENSION postgis?Tu build de PostgreSQL no incluye PostGIS. Elimina esa línea como se muestra en el paso 2 o usa una imagen con PostGIS.
schema.sql. El sitio queda listo para el primer inicio de sesión del administrador.051_likes_uci_favorites_indexes.sql. Tu desarrollador hace una copia de seguridad, aplica ese único archivo y vuelve a desplegar.051 y posteriores pueden incluir un archivo .down.sql correspondiente para revertir el cambio. Los archivos anteriores no lo tienen.DB_HOSTDB_PORTDB_NAMEDB_USERDB_PASSWORDDB_SSLDATABASE_URLEjecuta el siguiente paso como superusuario o como propietario de la base de datos, porque schema.sql crea extensiones.
Si tu servidor tiene PostGIS instalado (por ejemplo una imagen postgis/postgis), aplica el archivo tal cual:
En PostgreSQL sin PostGIS, elimina antes la línea de PostGIS. Ninguna tabla usa un tipo de PostGIS, así que no cambia nada más:
Da acceso al esquema public al rol de tu app (DB_USER) y después inicia la app.
Aplica solo los archivos que tu base de datos no ha visto. Algunas migraciones se registran en schema_versions con un INSERT ... WHERE NOT EXISTS (016 a 025, 037, 043 a 046, 050, 051). Las demás no, así que antes de aplicarlas comprueba si existen las tablas o índices que crean.
Para revertir una migración que incluye un archivo down, aplica 051_likes_uci_favorites_indexes.down.sql de la misma forma. También borra su fila de schema_versions.
Usa el siguiente número libre después del archivo más alto de data/migrations/. Hazlo idempotente (IF NOT EXISTS), regístralo en schema_versions y añade un .down.sql cuando el cambio sea reversible.
Esto ejecuta ring/scripts/flatten-schema-from-migrations.sh. Necesita un PostgreSQL local donde tu rol pueda crear bases de datos (PGHOST y PGUSER toman por defecto localhost y ring_user). Recrea una base de datos temporal ring_schema_flatten, guarda una copia de schema.sql como schema.sql.bak-pre-flatten-<timestamp>, aplica el esquema anterior más todas las migraciones excepto 001, vuelca el DDL más los datos de referencia y verifica el resultado en ring_schema_flatten_verify. El paso de verificación necesita PostGIS por el motivo indicado arriba.
No. El aplanado solo reescribe el archivo schema.sql del repositorio. Nunca toca las bases de datos en producción.
schema.sql antiguo. ¿Qué archivos necesito?Compara SELECT version FROM schema_versions con los archivos numerados y después aplica en orden los que falten, tras una copia de seguridad. Solo algunos archivos registran una versión (consulta Base de datos existente más arriba), así que en caso de duda comprueba sus tablas. Ten en cuenta que una instalación nueva con el schema.sql de hoy muestra versiones hasta 045, aunque las tablas e índices de 046 a 051 ya estén presentes.
CREATE EXTENSION postgis?Tu build de PostgreSQL no incluye PostGIS. Elimina esa línea como se muestra en el paso 2 o usa una imagen con PostGIS.
schema.sql. El sitio queda listo para el primer inicio de sesión del administrador.051_likes_uci_favorites_indexes.sql. Tu desarrollador hace una copia de seguridad, aplica ese único archivo y vuelve a desplegar.051 y posteriores pueden incluir un archivo .down.sql correspondiente para revertir el cambio. Los archivos anteriores no lo tienen.DB_HOSTDB_PORTDB_NAMEDB_USERDB_PASSWORDDB_SSLDATABASE_URLEjecuta el siguiente paso como superusuario o como propietario de la base de datos, porque schema.sql crea extensiones.
Si tu servidor tiene PostGIS instalado (por ejemplo una imagen postgis/postgis), aplica el archivo tal cual:
En PostgreSQL sin PostGIS, elimina antes la línea de PostGIS. Ninguna tabla usa un tipo de PostGIS, así que no cambia nada más:
Da acceso al esquema public al rol de tu app (DB_USER) y después inicia la app.
Aplica solo los archivos que tu base de datos no ha visto. Algunas migraciones se registran en schema_versions con un INSERT ... WHERE NOT EXISTS (016 a 025, 037, 043 a 046, 050, 051). Las demás no, así que antes de aplicarlas comprueba si existen las tablas o índices que crean.
Para revertir una migración que incluye un archivo down, aplica 051_likes_uci_favorites_indexes.down.sql de la misma forma. También borra su fila de schema_versions.
Usa el siguiente número libre después del archivo más alto de data/migrations/. Hazlo idempotente (IF NOT EXISTS), regístralo en schema_versions y añade un .down.sql cuando el cambio sea reversible.
Esto ejecuta ring/scripts/flatten-schema-from-migrations.sh. Necesita un PostgreSQL local donde tu rol pueda crear bases de datos (PGHOST y PGUSER toman por defecto localhost y ring_user). Recrea una base de datos temporal ring_schema_flatten, guarda una copia de schema.sql como schema.sql.bak-pre-flatten-<timestamp>, aplica el esquema anterior más todas las migraciones excepto 001, vuelca el DDL más los datos de referencia y verifica el resultado en ring_schema_flatten_verify. El paso de verificación necesita PostGIS por el motivo indicado arriba.
No. El aplanado solo reescribe el archivo schema.sql del repositorio. Nunca toca las bases de datos en producción.
schema.sql antiguo. ¿Qué archivos necesito?Compara SELECT version FROM schema_versions con los archivos numerados y después aplica en orden los que falten, tras una copia de seguridad. Solo algunos archivos registran una versión (consulta Base de datos existente más arriba), así que en caso de duda comprueba sus tablas. Ten en cuenta que una instalación nueva con el schema.sql de hoy muestra versiones hasta 045, aunque las tablas e índices de 046 a 051 ya estén presentes.
CREATE EXTENSION postgis?Tu build de PostgreSQL no incluye PostGIS. Elimina esa línea como se muestra en el paso 2 o usa una imagen con PostGIS.