What this category's data looks like
This page addresses the course selection, scheduling, and classroom resource allocation category. The materials include three types: course offering plans, scheduling tables, and course selection rules. Course offering plans provide the course name, course code, offering semester, and department signature; scheduling tables provide the classroom number, week number, period, start and end dates, and scheduler signature; course selection rules provide the selection capacity, selection time window, withdrawal and modification rules, and review receipt. When these three types of materials enter the deployment, operations, and application handover function, they respectively serve the roles of business data source, temporal and spatial constraints, and rule basis. The update cadence follows semester rounds: course offering plans are finalized first, scheduling tables are then locked, and course selection rules are frozen before course selection opens. The field characteristics are four types: dates, quantities, names, and signatures, which are compared item by item during handover.
Configuration and implementation checks
This step is performed by the connection configuration of the deployment environment (server side), not by the capability execution of a model node, and outputs whether the connection is available (service startup result and connection logs). "Handover-ready deployment status and operation records" are then completed by the deployment handover and subsequent business processing.
| Object | Check | Verification action |
|---|---|---|
| Primary business database connection variable | Points to the primary business database actually in use and can connect; the course code in the course offering plan, the classroom number in the scheduling table, and the capacity field in the course selection rules must match the records in the database item by item | In the deployment environment, check that the value of MONGODB_URI matches the database address, connect once with a client, and verify the response |
| Log database connection variable | Configured separately, or left empty per the instructions to reuse the primary database; the database to which logs are written is stored separately from the business records of the course offering plan, scheduling table, and course selection rules | Check whether the variable is set, verify the database to which logs are written, and confirm that business data is not mixed with logs in the same place |
| Cache connection variable | The cache instance can connect; the time window of the course selection rules and the period cache keys of the scheduling table can be read and written | Connect once to REDIS_URL with a client and verify the response; check the value of this variable against the deployment instructions |
| Vector database connection variable | Consistent with the vector database actually in use; the retrieval fields of the course offering plan and course selection rules can be matched | Check the selected vector database and the PG_URL address against the deployment instructions, and verify the value of this variable |
Three common errors
- Symptom: The name and quantity of the same course do not match between the course offering plan and the scheduling table. Cause: The two materials are updated separately and are not checked against the same version, and signatures or receipts are missing.
- Symptom: The dates in the scheduling table are inconsistent with the time window in the course selection rules. Cause: The versions are not synchronized, the old scheduling table is still in circulation, and the handover form lacks a date verification item.
- Symptom: After startup, the logs continuously report connection timeouts. Cause: The primary business database or cache connection variable is inconsistent with the actual instance, and handover is performed without connecting once item by item.
How to verify the setup
This function's acceptance: connect once to the primary business database, log database, cache, and vector database item by item, and verify the connection results in the startup logs; the values of MONGODB_URI, REDIS_URL, and PG_URL are consistent with the deployment instructions, and the connection response status is 200.
Business test: check item by item once according to the handover form to see which record is missing; check the fields, dates, and signatures of the course offering plan, scheduling table, and course selection rules one by one.
- Connect once to the primary business database, log database, cache, and vector database item by item, record the connection results and startup logs, and verify the values of
MONGODB_URI,REDIS_URL, andPG_URL. - Check the names, quantities, dates, and signatures of the course offering plan, scheduling table, and course selection rules according to the handover form, and confirm that the versions are consistent.