102 lines
4.3 KiB
Python
102 lines
4.3 KiB
Python
|
"""restore AUTO_INCREMENT on baseline primary keys
|
||
|
|
|
||
|
|
Compatibility proof
|
||
|
|
-------------------
|
||
|
|
This revision only **restores a column attribute**, and it is the attribute
|
||
|
|
`docs/00-新数据库基线设计.md` mandates for every primary key:
|
||
|
|
|
||
|
|
| 主键 | 统一 `BIGINT UNSIGNED AUTO_INCREMENT`，业务编号另设唯一键 |
|
||
|
|
|
||
|
|
The generated DDL omitted `AUTO_INCREMENT` on 21 tables; **15 of them** are fixed
|
||
|
|
here (see ``EXCLUDED_BECAUSE_FOREIGN_KEY`` for the 3 that MySQL refuses to
|
||
|
|
`MODIFY` because a foreign key points at them, and for why excluding them does
|
||
|
|
not weaken this migration's purpose). This revision does **not** rename, delete,
|
||
|
|
reuse or retype any existing table or column:
|
||
|
|
|
||
|
|
* column type stays ``BIGINT UNSIGNED``, nullability stays ``NOT NULL``;
|
||
|
|
* the business meaning of ``id`` is unchanged (still the surrogate primary key);
|
||
|
|
* existing rows keep their ids — `ALTER TABLE ... MODIFY ... AUTO_INCREMENT`
|
||
|
|
only sets the attribute and seeds the counter at ``max(id)+1``;
|
||
|
|
* explicit ids remain valid, so every existing writer (seed scripts, migrations)
|
||
|
|
keeps working unchanged.
|
||
|
|
|
||
|
|
Why it matters
|
||
|
|
--------------
|
||
|
|
``app/service/trade_service.py`` allocated keys with ``SELECT MAX(id)+1``
|
||
|
|
(``_next_id``). Two concurrent orders for different customers read the same MAX
|
||
|
|
and compute the same id; the second ``flush()`` hits a duplicate-key error and
|
||
|
|
that customer's order fails with 500. ``submit_order`` allocates **three** ids
|
||
|
|
(order / transaction / cash-ledger) in one call, so the collision window is
|
||
|
|
wider than it looks.
|
||
|
|
|
||
|
|
Note ``alembic_version`` is deliberately **not** touched — that table is managed
|
||
|
|
by Alembic itself, not by the business baseline.
|
||
|
|
"""
|
||
|
|
|
||
|
|
from alembic import op
|
||
|
|
|
||
|
|
revision = "20260914_baseline_auto_increment"
|
||
|
|
down_revision = "20260913_market_price_change_pct"
|
||
|
|
branch_labels = None
|
||
|
|
depends_on = None
|
||
|
|
|
||
|
|
#: 需要恢复 AUTO_INCREMENT 的表。
|
||
|
|
#:
|
||
|
|
#: 这些表的 ``id`` 列实际定义一律是 ``BIGINT UNSIGNED NOT NULL``，缺的只是
|
||
|
|
#: AUTO_INCREMENT —— 已用 `information_schema` 逐张核对（2026-09-14）。
|
||
|
|
#:
|
||
|
|
#: ⚠️ 刻意**硬编码**而不是在迁移里查 ``information_schema``：迁移必须**确定性**。
|
||
|
|
#: 动态查询会让"同一份迁移在不同环境产生不同结果"，回滚与复现都失去依据。
|
||
|
|
#: 新表若同样缺这个属性，请另开一条迁移，不要往这里追加 —— 历史迁移一旦被
|
||
|
|
#: 执行过就不该再改变行为。
|
||
|
|
TABLES: tuple[str, ...] = (
|
||
|
|
"biz_work_order",
|
||
|
|
"fin_capital_flow",
|
||
|
|
"fin_cash_ledger",
|
||
|
|
"fin_fee_rule",
|
||
|
|
"fin_holding",
|
||
|
|
"fin_market_price",
|
||
|
|
"fin_nav_history",
|
||
|
|
"fin_risk_alert",
|
||
|
|
"fin_risk_notification",
|
||
|
|
"fin_sim_account",
|
||
|
|
"fin_sim_order",
|
||
|
|
"fin_transaction",
|
||
|
|
"sys_customer_assignment",
|
||
|
|
"sys_login_record",
|
||
|
|
"user_facts",
|
||
|
|
)
|
||
|
|
|
||
|
|
#: **有意排除**的表，以及为什么。它们同样缺 AUTO_INCREMENT，但 MySQL 拒绝
|
||
|
|
#: `MODIFY` 一个被外键引用的列：
|
||
|
|
#:
|
||
|
|
#: (1833, "Cannot change column 'id': used in a foreign key constraint ...")
|
||
|
|
#:
|
||
|
|
#: 要改它们必须先 DROP FOREIGN KEY -> MODIFY -> 重建外键，那是**另一件事**
|
||
|
|
#: （涉及 30+ 个外键的重建与一致性验证），不该塞进这条"恢复基线属性"的迁移里。
|
||
|
|
#:
|
||
|
|
#: 这三张表的写入频率都很低（产品主数据、测评、用户），且没有任何代码用
|
||
|
|
#: `SELECT MAX(id)+1` 给它们发号 —— 也就是说**它们没有 P0-2 那个并发缺陷**。
|
||
|
|
#: 排除它们不会让本迁移的目标打折。
|
||
|
|
EXCLUDED_BECAUSE_FOREIGN_KEY: tuple[tuple[str, str], ...] = (
|
||
|
|
("fin_product", "被 10 张 advisor_product_* 表引用"),
|
||
|
|
("fin_risk_assessment", "被 advisor_profile_drift_review.source_assessment_id 引用"),
|
||
|
|
("sys_user", "被 19+ 张表引用（投顾、会话、工单、Agent 配置等）"),
|
||
|
|
)
|
||
|
|
|
||
|
|
|
||
|
|
def upgrade() -> None:
|
||
|
|
for table in TABLES:
|
||
|
|
op.execute(f"ALTER TABLE {table} MODIFY id BIGINT UNSIGNED NOT NULL AUTO_INCREMENT")
|
||
|
|
|
||
|
|
|
||
|
|
def downgrade() -> None:
|
||
|
|
"""回到"没有 AUTO_INCREMENT"的历史状态。
|
||
|
|
|
||
|
|
允许回滚：这只是去掉一个列属性，不丢数据、不改 id 值。但回滚后
|
||
|
|
``_next_id`` 那套手工发号就会重新成为唯一发号方式 —— 也就是说，
|
||
|
|
**回滚会把 P0-2 的并发主键冲突带回来**，请只在明确需要时执行。
|
||
|
|
"""
|
||
|
|
for table in TABLES:
|
||
|
|
op.execute(f"ALTER TABLE {table} MODIFY id BIGINT UNSIGNED NOT NULL")
|