From ece050d19fcee862d45e6b5ea70eb003ec5a475e Mon Sep 17 00:00:00 2001 From: Andrey Epifancev Date: Sun, 1 Nov 2026 12:00:14 +0400 Subject: [PATCH] =?UTF-8?q?fix(alembic):=20=D1=83=D1=81=D1=82=D1=80=D0=B0?= =?UTF-8?q?=D0=BD=D0=B8=D1=82=D1=8C=20=D0=B4=D1=83=D0=B1=D0=BB=D0=B8=D0=BA?= =?UTF-8?q?=D0=B0=D1=82=20revision=3D0051=20=D0=B2=20test=20(AURORA-1850)?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit При слиянии PR #244 в test оказались две миграции с revision="0051" и down_revision="0050" (upd_form_cells_full_rows из #231 и upd_form_cells_subtree из #244) — неоднозначная цепочка alembic. Фикс-коммит с переименованием 0051→0052 для #244 был подготовлен локально, но потерялся при повторном force-push после блокировки классификатором permission — слияние прошло с исходной (дублирующейся) нумерацией. Переносим upd_form_cells_subtree на 0052. Co-Authored-By: Claude Sonnet 5 --- ...form_cells_subtree.py => 0052_upd_form_cells_subtree.py} | 6 +++--- ...rm_cells_subtree.sql => 0052_upd_form_cells_subtree.sql} | 0 .../changes/aurora-1850-upd-form-cells-subtree/design.md | 1 + 3 files changed, 4 insertions(+), 3 deletions(-) rename api/alembic/versions/{0051_upd_form_cells_subtree.py => 0052_upd_form_cells_subtree.py} (59%) rename api/alembic/versions/sql/{0051_upd_form_cells_subtree.sql => 0052_upd_form_cells_subtree.sql} (100%) diff --git a/api/alembic/versions/0051_upd_form_cells_subtree.py b/api/alembic/versions/0052_upd_form_cells_subtree.py similarity index 59% rename from api/alembic/versions/0051_upd_form_cells_subtree.py rename to api/alembic/versions/0052_upd_form_cells_subtree.py index 25ed435..830fd41 100644 --- a/api/alembic/versions/0051_upd_form_cells_subtree.py +++ b/api/alembic/versions/0052_upd_form_cells_subtree.py @@ -1,14 +1,14 @@ from sql_migration import run_sql_file_migration -revision = "0051" -down_revision = "0050" +revision = "0052" +down_revision = "0051" branch_labels = None depends_on = None def upgrade() -> None: - run_sql_file_migration("0051_upd_form_cells_subtree.sql") + run_sql_file_migration("0052_upd_form_cells_subtree.sql") def downgrade() -> None: diff --git a/api/alembic/versions/sql/0051_upd_form_cells_subtree.sql b/api/alembic/versions/sql/0052_upd_form_cells_subtree.sql similarity index 100% rename from api/alembic/versions/sql/0051_upd_form_cells_subtree.sql rename to api/alembic/versions/sql/0052_upd_form_cells_subtree.sql diff --git a/openspec/changes/aurora-1850-upd-form-cells-subtree/design.md b/openspec/changes/aurora-1850-upd-form-cells-subtree/design.md index d1f1ae5..1de8ab2 100644 --- a/openspec/changes/aurora-1850-upd-form-cells-subtree/design.md +++ b/openspec/changes/aurora-1850-upd-form-cells-subtree/design.md @@ -287,3 +287,4 @@ | 2026-10-28 | Исполнитель Task 3 (T3.1): ранг скелета присоединяется внешним `JOIN sk` поверх `UNION` построителя, а не внутри веток; ключ скелета один bigint (узел = `-id`, строка = `lid`) | Вариант с `JOIN sk` в каждой ветке обрушил оценку строк, планировщик выбрал nested loop, GET AHR вырос со 105 до 203 мс; внешний JOIN даёт около 114 мс (+8 %) | Хрупкость плана на других объёмах; ловит замер GET на стенде | | 2026-10-28 | Исполнитель Task 4 (T4.4): JOIN `vsp` в скелете сателлитов оставлен, хотя `vsp_id` и `line_id` NOT NULL с FK (доказано по схеме); OTCH9F: перестановка строк с равным `(expense_item_id, month)` по tie-break `id` в снимке GET — 4 строки формы 26 (id 4/1 месяц 1, id 6/2 месяц 2), содержимое строк одинаково | Рулинг R-1; порядок при равных ключах раньше не был определён (D6) | Если фронт опирался на прежний случайный порядок равных ключей, порядок двух пар строк изменится | | 2026-10-29 | Контроллер (M-3): тест «0 вложенных `v_form_view`» жёстко требует `rolsuper` (assert вместо skip) | Рулинг R-2 | На не-суперпользовательской роли тест падает; нужен суперпользователь или проверка `has_parameter_privilege` | +| 2026-11-01 | Слияние в `test`: миграция переименована 0051→0052 (`down_revision` 0050→0051) | Коллизия revision=0050/0051 с независимо одобренными #229 (занял 0050) и #231 (переименован 0050→0051 при слиянии, тот же конфликт) — см. предсказание в proposal.md «Номер может измениться при rebase». Первая попытка исправления (PR #244) потерялась при force-push, из-за чего дубликат revision=0051 на короткое время попал в `test`; это PR отдельно устраняет его | Если номер не синхронизирован с реальным down_revision цепочки — alembic падает на дублирующейся ревизии (upgrade head становится неоднозначным) |