Files
paper-doc/backend/app/models/template_field.py
T
govin 13e5fc2cc1 backend: add section-field and paper-template schema, API, and seed data
Three tables behind the template configuration feature:

  section_field   the reusable heading library (name, level, font size,
                  colour)
  paper_template  a named outline (name, abstract)
  template_field  the join, and the only home of display order (sort)

The field library is deliberately flat. A `parent_id` would tie a level-2
heading to exactly one level-1 heading, and the point of the feature is that
a field such as "Background" can sit under both "1. Introduction" and
"2. Related Work" — and in any number of templates, at a different position
in each. Hierarchy is expressed only by `level`, which is a rendering hint.

Display order lives entirely in `template_field.sort`. The order fields were
picked in is never stored, so selecting fields out of order and assigning
sorts renders in sort order. Two consequences are intentional and documented
on the model: repeats are allowed (no unique constraint on template+field)
and ties are legal (broken by insertion order, so the ordering is total).

Templates reference library fields rather than copying them, so renaming or
restyling a field updates every template that places it.

TiDB parses FOREIGN KEY and then ignores it, so the constraints are declared
for documentation and the integrity is enforced in the application layer:
deleting a field still in use is refused with the field names, creating a
template against a missing field is refused, and deleting a template removes
its join rows through the ORM's delete-orphan cascade.

Also normalises font_color to #RRGGBB on write (accepting rgb() and
shorthand) and emits font_size as a JSON number rather than pydantic's
default Decimal string.

scripts/seed.py is idempotent and fills the library with a standard academic
outline plus three starter templates.
2026-09-18 15:56:47 +08:00

74 lines
2.8 KiB
Python

"""The template <-> field join table (关联表), which owns the display order.
This table is the heart of the design. It carries exactly one piece of
information that belongs to neither side alone: ``sort`` — where this field
sits in *this* template.
Consequences worth stating explicitly, because they are the requirements:
* A field can appear in many templates, at a different position in each.
* A field can legitimately appear **more than once** in the same template
(e.g. a level-2 "Background" under both "1. Introduction" and
"2. Related Work"), so there is deliberately **no** unique constraint on
``(template_id, field_id)``. The UI warns about repeats; it does not forbid
them.
* The user picks fields in any order they like. Nothing about the selection
order is stored — readers order strictly by ``sort``, then by ``id`` as a
stable tie-breaker.
"""
from typing import TYPE_CHECKING
from sqlalchemy import ForeignKey, Index, Integer
from sqlalchemy.orm import Mapped, mapped_column, relationship
from app.db.base import Base
if TYPE_CHECKING: # pragma: no cover - typing only
from app.models.paper_template import PaperTemplate
from app.models.section_field import SectionField
class TemplateField(Base):
"""One placement of one library field inside one template."""
__tablename__ = "template_field"
__table_args__ = (
# Every read is "the fields of template X, in order", so the index
# covers both the filter and the sort.
Index("ix_template_field_template_sort", "template_id", "sort"),
Index("ix_template_field_field_id", "field_id"),
)
id: Mapped[int] = mapped_column(primary_key=True, autoincrement=True)
template_id: Mapped[int] = mapped_column(
ForeignKey("paper_template.id", ondelete="CASCADE"),
nullable=False,
)
#: ``RESTRICT``: a field still placed in a template must not vanish from
#: under it. The API enforces this in Python as well, since TiDB does not
#: enforce foreign keys itself.
field_id: Mapped[int] = mapped_column(
ForeignKey("section_field.id", ondelete="RESTRICT"),
nullable=False,
)
#: Display position within the template. Plain ascending integer — lower
#: sorts render first regardless of the field's ``level``.
sort: Mapped[int] = mapped_column(Integer, nullable=False, default=0)
template: Mapped["PaperTemplate"] = relationship(back_populates="items")
#: Eager-loaded because every template read needs the field's name and
#: typography; lazy loading would emit one query per row.
field: Mapped["SectionField"] = relationship(lazy="joined")
def __repr__(self) -> str: # pragma: no cover - debugging aid
return (
f"<TemplateField template_id={self.template_id} "
f"field_id={self.field_id} sort={self.sort}>"
)