RSHB/DFiP_Budget_planing
9
0
Fork 0
Code Issues 30 Pull Requests 29 Actions Packages Projects Releases Wiki Activity

fix(alembic): устранить дубликат revision=0051 в test (AURORA-1850)

Browse Source 
При слиянии 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 <noreply@anthropic.com>
This commit is contained in:
Andrey Epifancev 2026-11-01 12:00:14 +04:00
parent 77f8957719
commit ece050d19f
3 changed files with 4 additions and 3 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

6
api/alembic/versions/0051_upd_form_cells_subtree.py → api/alembic/versions/0052_upd_form_cells_subtree.py
View File

@ -1,14 +1,14 @@
from sql_migration import run_sql_file_migration from sql_migration import run_sql_file_migration
revision = "0051" revision = "0052"
down_revision = "0050" down_revision = "0051"
branch_labels = None branch_labels = None
depends_on = None depends_on = None
def upgrade() -> 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: def downgrade() -> None:

0
api/alembic/versions/sql/0051_upd_form_cells_subtree.sql → api/alembic/versions/sql/0052_upd_form_cells_subtree.sql
View File

1
openspec/changes/aurora-1850-upd-form-cells-subtree/design.md
View File

@ -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 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-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-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 становится неоднозначным) |