refactor: prefix every table with its module

Two tables were named after the concept they came from rather than the module they belong to, so the schema read as if the template tables were part of the paper module. Renamed (data preserved, `RENAME TABLE` moves rows in place): paper_template -> template the 模板 module section_field -> template_field_library the 字段库 the 模板 module owns The paper tables and `template_field` already followed the rule. The rename carries through everything that named a module: models Template, TemplateField, TemplateFieldLibrary schemas Template*, TemplateFieldLibrary* crud app/crud/template.py, app/crud/template_field_library.py API /template-field-library (was /section-fields); handlers are now named after library entries, which removes the ambiguity with TemplateField — a placement, a different thing entirely client src/api/templateFieldLibrary.ts `paper_template_filed_sort` is deliberately untouched: it is a column of the paper module, spelled as the feature was specified. TiDB v8.5 with tidb_enable_foreign_key on — as this cluster runs — enforces foreign keys rather than ignoring them, so the docs' "TiDB does not enforce foreign keys" was wrong. Corrected, with what actually follows from it: the rename was rehearsed (RENAME TABLE carries a referencing constraint along), the API keeps checking first so a violation names the row instead of surfacing a driver error, and the ORM cascades stay so behaviour does not depend on a cluster setting. Revision f27a1c6d9e04 verified both ways; 40 smoke checks, type-check and build all pass.
2026-09-18 17:48:11 +08:00
parent 2d113f9f6b
commit a5f884f440
25 changed files with 371 additions and 260 deletions
@@ -0,0 +1,50 @@
+"""rename tables so every module prefixes its own
+
+Two tables were named after the concept they came from rather than the module
+they belong to, which made the schema read as if the template tables were part
+of the paper module:
+
+    paper_template   -> template                 the 模板 module
+    section_field    -> template_field_library   the 字段库, which the 模板 module
+                                                 owns and every template draws on
+
+The paper module (``paper``, ``paper_sentence``, ``paper_sentence_reference``)
+and the join table (``template_field``) already followed the rule and are not
+touched. After this revision the naming is:
+
+    template                  template_field        template_field_library
+    paper                     paper_sentence        paper_sentence_reference
+
+A rename, not a copy: ``RENAME TABLE`` moves the rows and leaves the data in
+place, and TiDB carries a referencing foreign key along with the renamed table
+(verified against the running cluster before this migration was written), so
+the constraints in ``template_field``, ``paper`` and ``paper_sentence`` now
+point at ``template`` and ``template_field_library`` with no drop/recreate
+step. Index names are left alone: they are per-table in MySQL and TiDB, and
+``template_field`` — whose indexes embed its own name — is not renamed.
+
+Revision ID: f27a1c6d9e04
+Revises: c41d7b09e5af
+Create Date: 2026-09-18
+
+"""
+
+from collections.abc import Sequence
+
+from alembic import op
+
+# revision identifiers, used by Alembic.
+revision: str = "f27a1c6d9e04"
+down_revision: str | None = "c41d7b09e5af"
+branch_labels: str | Sequence[str] | None = None
+depends_on: str | Sequence[str] | None = None
+
+
+def upgrade() -> None:
+    op.rename_table("paper_template", "template")
+    op.rename_table("section_field", "template_field_library")
+
+
+def downgrade() -> None:
+    op.rename_table("template_field_library", "section_field")
+    op.rename_table("template", "paper_template")