Section importers: Update to explicitly scope by district_school_year #2551
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Builds on #2550, and 47f2819#diff-cdc8b736dce9a3bd0db85d690b10d9e1 before.
Who is this PR for?
Somerville educators, internal team
What problem does this PR fix?
Somerville section assignment exports are now scoped by the
district_school_year
, which means there's now enough information to avoid collisions on primary keys across school years. Things likecourse_number
andsection_number
were recycled but with different values across semesters or years, and because of how the import processes for these worked historically (years back), this meant there were different variants of old orphaned records in theSection
table.Ideally, we'd be able to help educators look at information like student section enrollment and grades over time. To do this for grades specifically, it means that
Section
records need to have stable identities over time. The snapshots toHistoricalGrade
records does this in a limited way, but we haven't looked at this yet.What does this PR do?
This PR updates the importers processing a) course and sections, b) student section assignments, c) educator section assignments, and d) section grades, and their related tests. These all now expect
district_school_year
to be set explicitly, and scope the match process in the import to only look within that school year.The result is that running these in order should create a new set of
Section
records, explicitly scoped to a school year. And olderSection
records would stay in the database,Checklists
Which features or pages does this PR touch?
Does this PR use tests to help verify we can deploy these changes quickly and confidently?