What this category's data looks like
In the scheduling and class-hour consumption scenario of training institutions, materials mainly come from three types of documents: class schedules, class-hour consumption records, and schedule change requests. The update rhythm accumulates daily with scheduling adjustments, class-hour consumption, and temporary schedule changes. Field characteristics center on course name, student name, class-hour quantity, class date, signature, and receipt. When a class schedule enters this function, it serves as the baseline material, class-hour consumption records serve as the actual consumption material, and schedule change requests serve as the change material. The three types of materials each assume a comparison role, making it convenient to verify on the same object whether the name, quantity, and date are consistent, and to locate discrepancy fields.
Configuration and implementation checks
Parsing and training tasks (server-side tasks) only output data rows and index status (parsed, indexing, indexed). The discrepancy list must be handled next by retrieval and subsequent processing. After material parsing and chunking are completed, they are immediately persisted as visible data rows and bound to a unique data identifier. The index transitions through three states, and data pending indexing does not participate in recall.
| Object | Check | Verification action |
|---|---|---|
| Class schedule | Course name, class-hour quantity, class date, and signature fields are consistent in both materials | Verify the file record and the data row separately, check whether the data row status is parsed / indexing / indexed, and inspect the chunking results corresponding to chunkSize and chunkSplitter |
| Class-hour consumption record | The name, quantity, and date of the same record are consistent with the ledger | Open the data row to verify its status, confirm that data pending indexing is not recalled, and verify the processing mode corresponding to trainingType |
| Schedule change request | The change date and signature receipt are complete and the version is synchronized | Inspect the data rows covered by the rebuild task, and confirm that only data with completed indexing is covered |
| File and data row identifiers | The identities of the file record and the data row are distinguishable | Verify the file record and the data row separately, and confirm that the unique data identifier is bound correctly |
Three common errors
- Symptom: The name, quantity, or date of the same record does not match between the class schedule and the class-hour consumption record. Cause: The material sources are not synchronized, and the fields are not aligned to the same object.
- Symptom: The schedule change request lacks a signature or receipt, and the discrepancy list cannot be closed. Cause: The change material is not synchronized with the version, and the review lacks a basis.
- Symptom: Newly uploaded materials cannot be found. Cause: The data row is in a pending-indexing state, and the retrieval layer naturally isolates it from recall.
How to verify the setup
Acceptance for this function: Upload one material, observe the data row status transitions and the coverage scope of the rebuild task, confirm that the status is parsed / indexing / indexed, and verify the chunking and processing modes corresponding to chunkSize, chunkSplitter, and trainingType.
Business test: Use one real record to find a field inconsistent with the ledger, hand it to the reviewer for confirmation, and write it back.
- Open the data row to verify its status, confirm that it is consistent with the interface display, and verify the file record and the data row separately.
- Inspect the data rows covered by the rebuild task, and confirm that only data with completed indexing is covered.