Skip to content
New issue

Have a question about this project? # for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “#”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? # to your account

diagnostic-insights-show-data-with-no-assignments #12809

Draft
wants to merge 3 commits into
base: develop
Choose a base branch
from

Conversation

anathomical
Copy link
Contributor

@anathomical anathomical commented Feb 24, 2025

WHAT

Filter student_learning_sequences in Rails instead of SQL

WHY

The combination of JOINs for both non-ELL and ELL diagnostics in the SQL combined with filtering via WHERE for only non-ELL OR ELL diagnostics meant that if there were some non-ELL assignments, but no ELL diagnostics, specific User records were being removed from the results for ELL assignments. This could be solved in SQL by using an additional ON condition in the LEFT JOIN in SQL, but Rails does not provide a clean way of applying such a condition, so it's easiest to move this logic to Rails.

HOW

  • Remove a .where clause from the SQL that fetches data
  • Add an additional Ruby .select directive to the code that determines which StudentLearningSequence records to include in the returned payload

What have you done to QA this feature?

  • Deploy to staging
  • Using an account provided by Emilia, test on Staging to ensure that payloads are coming back for ELL in cases where non-ELL data exists instead of being buried.
PR Checklist Your Answer
Have you added and/or updated tests? Yes
Have you deployed to Staging? Yes
Self-Review: Have you done an initial self-review of the code below on Github? Yes

The combination of JOINs for both non-ELL and ELL diagnostics in the SQL combined with filtering via WHERE for only non-ELL OR ELL diagnostics meant that if there were some non-ELL assignments, but no ELL diagnostics, specific User records were being removed from the results.  This could be solved in SQL by using an additional ON condition in the SQL, but Rails does not provide a clean way of applying such a condition, so it's easiest to move this logic to Rails.
This allows us to avoid serializing records only to later exclude them, saving whatever time is required for serialization.
# for free to join this conversation on GitHub. Already have an account? # to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

1 participant