Benjamin Admin
f042f2896b
school-service additions:
- tt_solution + tt_lesson migration. tt_lesson carries three UNIQUEs
(solution+class, solution+teacher, solution+room per slot) so the
DB itself rejects any double-booking the solver might emit by
mistake.
- Solution CRUD + GET solutions/:id/lessons endpoint with joined
class/subject/teacher/room names for display.
- POST /timetable/solutions creates the row then fires off the
solver-service via HTTP (5s timeout, mark failed if unreachable).
- SOLVER_SERVICE_URL config wired through main.go/handlers.
New service timetable-solver-service:
- Python 3.11 + FastAPI + Timefold Solver 1.21 (Apache-2.0). Dockerfile
bundles OpenJDK 17 since Timefold for Python is a JPype bridge.
- app/domain.py — Timefold @planning_entity Lesson with timeslot+room
as PlanningVariables; @planning_solution Timetable holds problem
facts (rooms/teachers/etc.) AND rule-fact collections.
- app/rules.py — frozen dataclasses mirroring 6 of the 15 tt_
constraint_* tables initially.
- app/constraints.py — ConstraintProvider with 3 universal hard
constraints (no double-booking) + 5 DB-driven constraints
(teacher_unavailable_day/window, teacher_excluded_room,
room_unavailable, room_requires_type) + 1 quality soft constraint
(subject_preferred_period). Remaining 9 constraint types ready to
plug in via the same join pattern.
- app/repository.py — async loaders for stammdaten + rules; builds
one Lesson per (curriculum row × weekly_hours), skipping rows
without a tt_assignment teacher.
- app/runner.py — runs solver in ThreadPoolExecutor so the FastAPI
event loop stays responsive. Updates tt_solution status
pending→running→completed|infeasible|failed.
- app/main.py — POST /api/v1/solve (202 Accepted, background task),
GET /api/v1/jobs/{id}, /health. School-service polls tt_solution
directly instead of GET /jobs for the typical case.
- docker-compose.yml adds the service on port 8095, depending on
core-health-check.
Tests:
- school-service: validator test for CreateTimetableSolutionRequest
(allows empty name).
- solver-service: tests/test_domain.py + tests/test_rules.py cover
construction + hashability of the planning facts. Full solve flow
deferred to Phase 8 integration with seed data.
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
65 lines
1.4 KiB
Python
65 lines
1.4 KiB
Python
"""DB-driven constraint rules as Timefold problem facts.
|
|
|
|
Each tt_constraint_* table from school-service maps to one dataclass here.
|
|
Rows loaded at solve time are passed in via Timetable.* fact collections
|
|
(see domain.py for wiring) and queried by the constraint provider.
|
|
|
|
Only the rule types actually wired into constraints.py are defined for now.
|
|
Adding a new one is two steps: define the dataclass, add it to Timetable's
|
|
problem-fact properties, then implement a constraint that joins it.
|
|
"""
|
|
|
|
from dataclasses import dataclass
|
|
|
|
|
|
@dataclass(frozen=True)
|
|
class TeacherUnavailableDayRule:
|
|
teacher_id: str
|
|
day_of_week: int
|
|
is_hard: bool
|
|
weight: int
|
|
|
|
|
|
@dataclass(frozen=True)
|
|
class TeacherUnavailableWindowRule:
|
|
teacher_id: str
|
|
day_of_week: int
|
|
start_time: str # HH:MM
|
|
end_time: str # HH:MM
|
|
is_hard: bool
|
|
weight: int
|
|
|
|
|
|
@dataclass(frozen=True)
|
|
class TeacherExcludedRoomRule:
|
|
teacher_id: str
|
|
room_id: str
|
|
is_hard: bool
|
|
weight: int
|
|
|
|
|
|
@dataclass(frozen=True)
|
|
class RoomUnavailableRule:
|
|
room_id: str
|
|
day_of_week: int
|
|
period_index: int
|
|
is_hard: bool
|
|
weight: int
|
|
|
|
|
|
@dataclass(frozen=True)
|
|
class SubjectPreferredPeriodRule:
|
|
subject_id: str
|
|
period_from: int
|
|
period_to: int
|
|
is_hard: bool
|
|
weight: int
|
|
|
|
|
|
@dataclass(frozen=True)
|
|
class RoomRequiresTypeRule:
|
|
subject_id: str
|
|
room_type: str
|
|
is_hard: bool
|
|
weight: int
|