perf: LSDV-4695: update Prediction model queries to take advantage of new direct project relation #4639
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
…ove performance Also update anywhere in the code where Predictions are created so project is also connected and adds a failsafe in the Predition save method to add a project if it was not added before
✅ Deploy Preview for label-studio-docs-new-theme canceled.
|
✅ Deploy Preview for heartex-docs canceled.
|
Codecov ReportPatch has no changes to coverable lines.
📢 Thoughts on this report? Let us know!. |
# Conflicts: # label_studio/data_import/api.py # label_studio/tasks/migrations/0042_auto_20230810_2304.py
wesleylima
approved these changes
Sep 1, 2023
makseq
requested changes
Sep 6, 2023
# Conflicts: # label_studio/tasks/serializers.py
makseq
approved these changes
Sep 11, 2023
|
/git merge develop
|
jombooth
pushed a commit
that referenced
this pull request
Sep 13, 2023
… new direct project relation (#4639) * perf: LSDV-4695: add new project relation to Prediction model to improve performance Also update anywhere in the code where Predictions are created so project is also connected and adds a failsafe in the Predition save method to add a project if it was not added before * Add data migration to update predictions with direct fk to their project * perf: LSDV-4695: update queries to handle new Prediction -> project pk * Add missing import
shayantabatabaee
pushed a commit
to shayantabatabaee/label-studio
that referenced
this pull request
Sep 19, 2023
… new direct project relation (HumanSignal#4639) * perf: LSDV-4695: add new project relation to Prediction model to improve performance Also update anywhere in the code where Predictions are created so project is also connected and adds a failsafe in the Predition save method to add a project if it was not added before * Add data migration to update predictions with direct fk to their project * perf: LSDV-4695: update queries to handle new Prediction -> project pk * Add missing import
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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.
PR fulfills these requirements
[fix|feat|ci|chore|doc]: TICKET-ID: Short description of change madeex.fix: DEV-XXXX: Removed inconsistent code usage causing intermittent errorsChange has impacts in these area(s)
(check all that apply)
Describe the reason for change
Prediction performance in general has not been optimal due to the necessity of querying through the task model whenever needing to filter on project (
Prediction->Task->Project).What does this fix?
This PR updates all
Predictionqueries that access project through task (a double join) to access project directly through thePredictionmodel's new project fk (added in this PR).Does this change affect performance?
This PR should positively impact performance in any location
Predictionqueries are made onProject.What feature flags were used to cover this change?
fflag_perf_back_lsdv_4695_update_prediction_query_to_use_direct_project_relationDoes this PR introduce a breaking change?
(check only one)
What level of testing was included in the change?
(check all that apply)
Which logical domain(s) does this change affect?
Predictions