What this category's data looks like
This page addresses primary and secondary school student status establishment and change scenarios, with materials coming from three categories: student status archives, transfer applications, and suspension/resumption materials. Student status archives mainly contain student basic information, guardian information, photos, and household registration fields; transfer applications carry the transferring-in and transferring-out schools, grade, date, and signatures of both parties; suspension/resumption materials record the reason for suspension, start and end dates, resumption receipt, and approval opinions. Materials are updated by semester and change event, with high field density and scattered date and signature locations. After entering this function, the three categories of materials serve as objects to be parsed respectively, and the parsed chunks are immediately persisted as visible data rows upon completion of parsing and bound to a unique data identifier, for use in subsequent retrieval and discrepancy localization.
Configuration and implementation checks
This step is executed by the parsing and training task (server-side task), outputting data rows and index status (parsed, indexing, indexed). The "discrepancy list" is then completed by retrieval and subsequent processing.
| Object | Check | Verification action |
|---|---|---|
| Student status archive | Name, date, and signature are consistent across the three categories of materials | Check whether the data row status is parsed / indexing / indexed, and compare the name and date of birth fields |
| Transfer application | Transferring-in and transferring-out schools, grade, and date match up | Check the file record and the data row separately, and inspect whether the date field crosses chunks after splitting by chunkSize and chunkSplitter |
| Suspension/resumption materials | Suspension start and end dates and resumption receipt are complete | Look at the data rows covered by the rebuild task, and confirm the mode corresponding to trainingType and the signature receipt field |
| Ledger record | The quantity and date of the same object are consistent in the two materials | Use one real record to find the field inconsistent with the ledger, and mark the discrepancy location |
Three common errors
- Symptom: The name or date of birth of the same student does not match between the student status archive and the transfer application. Cause: The two materials have different entry sources, and no field-level comparison and write-back were performed.
- Symptom: Suspension/resumption materials lack a signature or receipt but are still treated as complete records. Cause: Material verification only checks whether fields exist, without verifying the signature and receipt locations.
- Symptom: Newly uploaded materials cannot be found, or rebuilding after changing models takes abnormally long. Cause: Data pending indexing does not participate in recall, and rebuilding only covers data that has already completed indexing.
How to verify the setup
This function's acceptance: upload one material, and observe the data row status transitions and the coverage scope of the rebuild task.
Business test: use one real record to find the field inconsistent with the ledger.
- Open the data row to check the status, and confirm it is one of parsed / indexing / indexed and consistent with the interface display.
- Check the file record and the data row separately, and inspect the splitting and training modes corresponding to
chunkSize,chunkSplitter, andtrainingType.