Концепции, ценность и типичные сценарии клонирования — меньше кода.
Концепции, ценность и типичные сценарии клонирования — меньше кода.
Preparing Ring content
Preparing Ring content
Preparing Ring content
Ring хранит схему PostgreSQL в двух местах внутри ring/web/data/. schema.sql является сплющенным единый источник истины для новых баз. migrations/ содержит пронумерованные инкрементальные файлы, которые привели существующие базы к той же форме. Эта страница объясняет, какой путь применять и когда.
Используйте вкладки Основатель / Разработчик в боковой панели документации, чтобы отфильтровать эту страницу. Общие разделы относятся к обеим аудиториям.
Статус: ./install.sh setup-db и npm run db:apply-schema сейчас падают на публичных checkout, потому что ищут пути, которые переехали под web/. Кроме того, schema.sql содержит CREATE EXTENSION IF NOT EXISTS postgis;, поэтому обычный psql -f data/schema.sql останавливается с ошибкой на образах PostgreSQL без PostGIS (например postgres:16-alpine). Используйте команды из шага 2 ниже.
| Раньше в документации | Текущее поведение |
|---|---|
Применить schema.sql, затем 002, 003, 004 по порядку | Свежие установки применяют только web/data/schema.sql (сплющенный, версия 4.1.0) |
Запустить ./scripts/run-migration.sh или apply-*-migrations-dev.sh | Эти хелперы отсутствуют в публичном дереве. Используйте psql напрямую |
Установить Homebrew postgresql@18 с bootstrap-скриптом | Подойдёт любой PostgreSQL 16 или новее. Bootstrap-скрипт внутренний для Ringdom |
Сеять новости из scripts/seed-news-v1.6.0.sql | Этого файла нет. Сиды для валют, стран, настроек магазина и категорий новостей находятся внутри schema.sql |
data/schema-delta.sql | Не используется. Дельты живут как пронумерованные файлы в data/migrations/ |
Вам не нужно понимать SQL, чтобы запускать клон Ring, но стоит знать правило, которому следует ваш разработчик: новая база получает один файл, существующая база получает только новые файлы. Именно это правило делает обновления скучными и предсказуемыми.
Один файл схемы создаёт все таблицы (109 на версии 4.1.0) плюс эталонные сиды. Без повторного проигрывания истории.
Ваш разработчик применяет только те пронумерованные файлы, которых база ещё не видела, после бэкапа.
PostgreSQL является типичным production-бэкенд (k8s-postgres-fcm).
Next-step: run the app against the database you just created.
Same-workflow: apply the schema to the compose Postgres container.
Prerequisite: why k8s-postgres-fcm needs this schema.
See-also: install.sh and the npm db scripts, including the ones that fail today.
Ring хранит схему PostgreSQL в двух местах внутри ring/web/data/. schema.sql является сплющенным единый источник истины для новых баз. migrations/ содержит пронумерованные инкрементальные файлы, которые привели существующие базы к той же форме. Эта страница объясняет, какой путь применять и когда.
Используйте вкладки Основатель / Разработчик в боковой панели документации, чтобы отфильтровать эту страницу. Общие разделы относятся к обеим аудиториям.
Статус: ./install.sh setup-db и npm run db:apply-schema сейчас падают на публичных checkout, потому что ищут пути, которые переехали под web/. Кроме того, schema.sql содержит CREATE EXTENSION IF NOT EXISTS postgis;, поэтому обычный psql -f data/schema.sql останавливается с ошибкой на образах PostgreSQL без PostGIS (например postgres:16-alpine). Используйте команды из шага 2 ниже.
| Раньше в документации | Текущее поведение |
|---|---|
Применить schema.sql, затем 002, 003, 004 по порядку | Свежие установки применяют только web/data/schema.sql (сплющенный, версия 4.1.0) |
Запустить ./scripts/run-migration.sh или apply-*-migrations-dev.sh | Эти хелперы отсутствуют в публичном дереве. Используйте psql напрямую |
Установить Homebrew postgresql@18 с bootstrap-скриптом | Подойдёт любой PostgreSQL 16 или новее. Bootstrap-скрипт внутренний для Ringdom |
Сеять новости из scripts/seed-news-v1.6.0.sql | Этого файла нет. Сиды для валют, стран, настроек магазина и категорий новостей находятся внутри schema.sql |
data/schema-delta.sql | Не используется. Дельты живут как пронумерованные файлы в data/migrations/ |
Вам не нужно понимать SQL, чтобы запускать клон Ring, но стоит знать правило, которому следует ваш разработчик: новая база получает один файл, существующая база получает только новые файлы. Именно это правило делает обновления скучными и предсказуемыми.
Один файл схемы создаёт все таблицы (109 на версии 4.1.0) плюс эталонные сиды. Без повторного проигрывания истории.
Ваш разработчик применяет только те пронумерованные файлы, которых база ещё не видела, после бэкапа.
PostgreSQL является типичным production-бэкенд (k8s-postgres-fcm).
Next-step: run the app against the database you just created.
Same-workflow: apply the schema to the compose Postgres container.
Prerequisite: why k8s-postgres-fcm needs this schema.
See-also: install.sh and the npm db scripts, including the ones that fail today.
Ring хранит схему PostgreSQL в двух местах внутри ring/web/data/. schema.sql является сплющенным единый источник истины для новых баз. migrations/ содержит пронумерованные инкрементальные файлы, которые привели существующие базы к той же форме. Эта страница объясняет, какой путь применять и когда.
Используйте вкладки Основатель / Разработчик в боковой панели документации, чтобы отфильтровать эту страницу. Общие разделы относятся к обеим аудиториям.
Статус: ./install.sh setup-db и npm run db:apply-schema сейчас падают на публичных checkout, потому что ищут пути, которые переехали под web/. Кроме того, schema.sql содержит CREATE EXTENSION IF NOT EXISTS postgis;, поэтому обычный psql -f data/schema.sql останавливается с ошибкой на образах PostgreSQL без PostGIS (например postgres:16-alpine). Используйте команды из шага 2 ниже.
| Раньше в документации | Текущее поведение |
|---|---|
Применить schema.sql, затем 002, 003, 004 по порядку | Свежие установки применяют только web/data/schema.sql (сплющенный, версия 4.1.0) |
Запустить ./scripts/run-migration.sh или apply-*-migrations-dev.sh | Эти хелперы отсутствуют в публичном дереве. Используйте psql напрямую |
Установить Homebrew postgresql@18 с bootstrap-скриптом | Подойдёт любой PostgreSQL 16 или новее. Bootstrap-скрипт внутренний для Ringdom |
Сеять новости из scripts/seed-news-v1.6.0.sql | Этого файла нет. Сиды для валют, стран, настроек магазина и категорий новостей находятся внутри schema.sql |
data/schema-delta.sql | Не используется. Дельты живут как пронумерованные файлы в data/migrations/ |
Вам не нужно понимать SQL, чтобы запускать клон Ring, но стоит знать правило, которому следует ваш разработчик: новая база получает один файл, существующая база получает только новые файлы. Именно это правило делает обновления скучными и предсказуемыми.
Один файл схемы создаёт все таблицы (109 на версии 4.1.0) плюс эталонные сиды. Без повторного проигрывания истории.
Ваш разработчик применяет только те пронумерованные файлы, которых база ещё не видела, после бэкапа.
PostgreSQL является типичным production-бэкенд (k8s-postgres-fcm).
Next-step: run the app against the database you just created.
Same-workflow: apply the schema to the compose Postgres container.
Prerequisite: why k8s-postgres-fcm needs this schema.
See-also: install.sh and the npm db scripts, including the ones that fail today.
schema.sql. Сайт готов к первому логину админа.051_likes_uci_favorites_indexes.sql. Ваш разработчик делает бэкап, применяет этот один файл и передеплоит.051 и новее могут иметь соответствующий .down.sql, чтобы изменение можно было откатить. Более старые файлы нет.DB_HOSTDB_PORTDB_NAMEDB_USERDB_PASSWORDDB_SSLDATABASE_URLСледующий шаг выполняйте как суперпользователь или владелец базы, потому что schema.sql создаёт расширения.
Если на сервере установлен PostGIS (например образ postgis/postgis), примените файл как есть:
На обычном PostgreSQL сначала уберите строку PostGIS. Ни одна таблица не использует тип PostGIS, поэтому больше ничего не меняется:
Дайте роли приложения (DB_USER) доступ к схеме public, затем запустите приложение.
Применяйте только файлы, которых база ещё не видела. Некоторые миграции записывают себя в schema_versions через INSERT ... WHERE NOT EXISTS (016 до 025, 037, 043 до 046, 050, 051). Остальные этого не делают, поэтому перед применением проверяйте наличие таблиц или индексов, которые они создают.
Чтобы откатить миграцию с down-файлом, примените 051_likes_uci_favorites_indexes.down.sql так же. Он также удаляет свою строку в schema_versions.
Возьмите следующий свободный номер после самого высокого файла в data/migrations/. Сделайте его идемпотентным (IF NOT EXISTS), запишите в schema_versions и добавьте .down.sql, когда изменение обратимо.
Это запускает ring/scripts/flatten-schema-from-migrations.sh. Нужен локальный PostgreSQL, где ваша роль может создавать базы (PGHOST и PGUSER по умолчанию localhost и ring_user). Скрипт создаёт scratch-базу ring_schema_flatten, бэкапит schema.sql как schema.sql.bak-pre-flatten-<timestamp>, применяет предыдущую схему плюс все миграции кроме 001, дампит DDL плюс эталонные сиды и проверяет результат на ring_schema_flatten_verify. Шаг verify требует PostGIS по той же причине, что выше.
Нет. Сплющивание только переписывает файл schema.sql в репозитории. Живые базы оно никогда не трогает.
schema.sql. Какие файлы мне нужны?Сравните SELECT version FROM schema_versions с пронумерованными файлами, затем примените недостающие по порядку после бэкапа. Только некоторые файлы записывают версию (см. «Существующая база» выше), поэтому при сомнении проверяйте их таблицы. Обратите внимание: свежая установка из сегодняшнего schema.sql показывает версии до 045, хотя таблицы и индексы из 046 до 051 уже присутствуют.
CREATE EXTENSION postgis?Ваша сборка PostgreSQL не включает PostGIS. Уберите эту строку, как показано в шаге 2, или используйте образ с PostGIS.
schema.sql. Сайт готов к первому логину админа.051_likes_uci_favorites_indexes.sql. Ваш разработчик делает бэкап, применяет этот один файл и передеплоит.051 и новее могут иметь соответствующий .down.sql, чтобы изменение можно было откатить. Более старые файлы нет.DB_HOSTDB_PORTDB_NAMEDB_USERDB_PASSWORDDB_SSLDATABASE_URLСледующий шаг выполняйте как суперпользователь или владелец базы, потому что schema.sql создаёт расширения.
Если на сервере установлен PostGIS (например образ postgis/postgis), примените файл как есть:
На обычном PostgreSQL сначала уберите строку PostGIS. Ни одна таблица не использует тип PostGIS, поэтому больше ничего не меняется:
Дайте роли приложения (DB_USER) доступ к схеме public, затем запустите приложение.
Применяйте только файлы, которых база ещё не видела. Некоторые миграции записывают себя в schema_versions через INSERT ... WHERE NOT EXISTS (016 до 025, 037, 043 до 046, 050, 051). Остальные этого не делают, поэтому перед применением проверяйте наличие таблиц или индексов, которые они создают.
Чтобы откатить миграцию с down-файлом, примените 051_likes_uci_favorites_indexes.down.sql так же. Он также удаляет свою строку в schema_versions.
Возьмите следующий свободный номер после самого высокого файла в data/migrations/. Сделайте его идемпотентным (IF NOT EXISTS), запишите в schema_versions и добавьте .down.sql, когда изменение обратимо.
Это запускает ring/scripts/flatten-schema-from-migrations.sh. Нужен локальный PostgreSQL, где ваша роль может создавать базы (PGHOST и PGUSER по умолчанию localhost и ring_user). Скрипт создаёт scratch-базу ring_schema_flatten, бэкапит schema.sql как schema.sql.bak-pre-flatten-<timestamp>, применяет предыдущую схему плюс все миграции кроме 001, дампит DDL плюс эталонные сиды и проверяет результат на ring_schema_flatten_verify. Шаг verify требует PostGIS по той же причине, что выше.
Нет. Сплющивание только переписывает файл schema.sql в репозитории. Живые базы оно никогда не трогает.
schema.sql. Какие файлы мне нужны?Сравните SELECT version FROM schema_versions с пронумерованными файлами, затем примените недостающие по порядку после бэкапа. Только некоторые файлы записывают версию (см. «Существующая база» выше), поэтому при сомнении проверяйте их таблицы. Обратите внимание: свежая установка из сегодняшнего schema.sql показывает версии до 045, хотя таблицы и индексы из 046 до 051 уже присутствуют.
CREATE EXTENSION postgis?Ваша сборка PostgreSQL не включает PostGIS. Уберите эту строку, как показано в шаге 2, или используйте образ с PostGIS.
schema.sql. Сайт готов к первому логину админа.051_likes_uci_favorites_indexes.sql. Ваш разработчик делает бэкап, применяет этот один файл и передеплоит.051 и новее могут иметь соответствующий .down.sql, чтобы изменение можно было откатить. Более старые файлы нет.DB_HOSTDB_PORTDB_NAMEDB_USERDB_PASSWORDDB_SSLDATABASE_URLСледующий шаг выполняйте как суперпользователь или владелец базы, потому что schema.sql создаёт расширения.
Если на сервере установлен PostGIS (например образ postgis/postgis), примените файл как есть:
На обычном PostgreSQL сначала уберите строку PostGIS. Ни одна таблица не использует тип PostGIS, поэтому больше ничего не меняется:
Дайте роли приложения (DB_USER) доступ к схеме public, затем запустите приложение.
Применяйте только файлы, которых база ещё не видела. Некоторые миграции записывают себя в schema_versions через INSERT ... WHERE NOT EXISTS (016 до 025, 037, 043 до 046, 050, 051). Остальные этого не делают, поэтому перед применением проверяйте наличие таблиц или индексов, которые они создают.
Чтобы откатить миграцию с down-файлом, примените 051_likes_uci_favorites_indexes.down.sql так же. Он также удаляет свою строку в schema_versions.
Возьмите следующий свободный номер после самого высокого файла в data/migrations/. Сделайте его идемпотентным (IF NOT EXISTS), запишите в schema_versions и добавьте .down.sql, когда изменение обратимо.
Это запускает ring/scripts/flatten-schema-from-migrations.sh. Нужен локальный PostgreSQL, где ваша роль может создавать базы (PGHOST и PGUSER по умолчанию localhost и ring_user). Скрипт создаёт scratch-базу ring_schema_flatten, бэкапит schema.sql как schema.sql.bak-pre-flatten-<timestamp>, применяет предыдущую схему плюс все миграции кроме 001, дампит DDL плюс эталонные сиды и проверяет результат на ring_schema_flatten_verify. Шаг verify требует PostGIS по той же причине, что выше.
Нет. Сплющивание только переписывает файл schema.sql в репозитории. Живые базы оно никогда не трогает.
schema.sql. Какие файлы мне нужны?Сравните SELECT version FROM schema_versions с пронумерованными файлами, затем примените недостающие по порядку после бэкапа. Только некоторые файлы записывают версию (см. «Существующая база» выше), поэтому при сомнении проверяйте их таблицы. Обратите внимание: свежая установка из сегодняшнего schema.sql показывает версии до 045, хотя таблицы и индексы из 046 до 051 уже присутствуют.
CREATE EXTENSION postgis?Ваша сборка PostgreSQL не включает PostGIS. Уберите эту строку, как показано в шаге 2, или используйте образ с PostGIS.