Skip to content
New issue

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

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

Already on GitHub? Sign in to your account

Fix and Refactor Querying of template.phases and Associations Within OrgAdmin TemplatesController #991

Open
wants to merge 5 commits into
base: integration
Choose a base branch
from

Conversation

aaronskiba
Copy link
Collaborator

Fixes #955

Changes proposed in this PR:

  • Address ambiguity and remove one-to-many columns from .select() clause ca52b91

    • Prior to this commit, both 'phases.title' and 'sections.title' were included in the .select() clause. Since 'sections.title' was listed after 'phases.title', phases.first.title, would evaluate to the sections.title value.
    • A phase can have multiple sections, questions, and question_options, so including columns like sections.title in .select() is not appropriate.
    • No additional handling is needed since we're already using .includes(sections: { questions: :question_options }) to preload the associations, and phase.sections.each etc. handles the associations properly within the view.
  • Refactor fetching of template.phases b18a454

    • There were identical phases queries within the view and edit actions. This refactor makes the query accessible by calling the fetch_template_phases method.
  • Fix and refactor ordering of template associations c7921b4

    • Removed .order() as it was only applied to the main phases query and did not guarantee the order of associated records (e.g., question_options), which are loaded in separate queries.
    • default_scope { order(number: :asc) } already exists for the Phase, Section, and Question models, ensuring the desired ordering by default.
    • The QuestionOption model includes scope :by_number, -> { order(:number) }, which is now explicitly applied when fetching the question_options association to enable proper ordering.
    • .order() must've been auto-including :id in the .select() clause. Since it is required, we are explicitly adding it now.
  • Refactor/optimise check for question_options db92f3b

    • Replaced .length > 0 with .any? to improve readability and performance.
    • .any? is more efficient for checking if a collection has elements, especially for ActiveRecord associations, as it doesn't require loading the entire collection into memory.

"Fix ambiguity":
- Prior to this commit, both 'phases.title' and 'sections.title' were included in the `.select()` clause. Since 'sections.title' was listed after 'phases.title', `phases.first.title`, would resolve to the corresponding `sections.title`.

"Remove 1-to-many `.select()` columns":
- A phase can have multiple sections, questions, and question_options, so including columns like `sections.title` in `.select()` is not appropriate.
- No additional handling is needed since we're already using `.includes(sections: { questions: :question_options })` to preload the associations, and `phase.sections.each` etc. handles the associations properly within the view.
Lines 107-111 and 131-136 were identical. Created `def fetch_template_phases` to be called instead.
- Removed `.order()` as it was only applied to the main phases query and did not guarantee the order of associated records (e.g., `question_options`), which are loaded in separate queries.

- `default_scope { order(number: :asc) }` already exists for the `Phase`, `Section`, and `Question` models, ensuring the desired ordering by default.

- The `QuestionOption` model includes  `scope :by_number, -> { order(:number) }`, which is now explicitly applied when fetching the `question_options` association to enable proper ordering.

- `.order()` must've been auto-including `:id` in the `.select()` clause. Since it is required, we are explicitly adding it now.
- Replaced `.length > 0` with `.any?` to improve readability and performance.
- `.any?` is more efficient for checking if a collection has elements, especially for ActiveRecord associations, as it doesn't require loading the entire collection into memory.
@aaronskiba aaronskiba changed the title Fix and Refactor Querying of template.phases and Associations Within OrgAdmin TemplatesController Fix and Refactor Querying of template.phases and Associations Within OrgAdmin TemplatesController Jan 8, 2025
@aaronskiba
Copy link
Collaborator Author

The PR DMPRoadmap#3472 applies the same changes to the repo that we are forked off of.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

1 participant