a5f884f440
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.
55 lines
1.9 KiB
Python
55 lines
1.9 KiB
Python
"""SQLAlchemy ORM models.
|
|
|
|
Importing this package registers every model on ``Base.metadata``, which is
|
|
what ``alembic revision --autogenerate`` inspects. A new model therefore has to
|
|
be added to the imports below, not only to its own module.
|
|
|
|
The import order here is for readability only: relationships are declared by
|
|
name and resolved through the SQLAlchemy registry after every module has been
|
|
imported, so a cycle between two model modules is not a problem.
|
|
|
|
Table naming
|
|
------------
|
|
Every table is prefixed with the module it belongs to, and a class is named
|
|
after its table (``Template`` -> ``template``):
|
|
|
|
template the 模板 module
|
|
template_field a field placed in a template, with its position
|
|
template_field_library the 字段库 the template module draws on
|
|
paper the 论文 module
|
|
paper_sentence one sentence of one paper
|
|
paper_sentence_reference a citation of one sentence
|
|
|
|
``template_field`` and ``template_field_library`` are one word apart and mean
|
|
opposite things: the first is a *placement* (this template puts this field
|
|
here, ``sort`` included), the second is the *catalogue* it was picked from.
|
|
"""
|
|
|
|
from app.models.mixins import TimestampMixin
|
|
from app.models.paper import (
|
|
PAPER_STATUSES,
|
|
STATUS_DONE,
|
|
STATUS_DRAFT,
|
|
STATUS_WRITING,
|
|
Paper,
|
|
)
|
|
from app.models.paper_sentence import PaperSentence
|
|
from app.models.paper_sentence_reference import PaperSentenceReference
|
|
from app.models.template import Template
|
|
from app.models.template_field import TemplateField
|
|
from app.models.template_field_library import TemplateFieldLibrary
|
|
|
|
__all__ = [
|
|
"PAPER_STATUSES",
|
|
"STATUS_DONE",
|
|
"STATUS_DRAFT",
|
|
"STATUS_WRITING",
|
|
"Paper",
|
|
"PaperSentence",
|
|
"PaperSentenceReference",
|
|
"Template",
|
|
"TemplateField",
|
|
"TemplateFieldLibrary",
|
|
"TimestampMixin",
|
|
]
|