-
Notifications
You must be signed in to change notification settings - Fork 3.4k
Fix inconsistent related_names and related_query_names in engine models
#9621
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
Conversation
|
/check |
|
🚫 Workflows has been canceled |
|
cvat/apps/engine/models.py
Outdated
| on_delete=models.SET_NULL, related_name="owners") | ||
| on_delete=models.SET_NULL, related_name="tasks", related_query_name="task") | ||
| assignee = models.ForeignKey(User, null=True, blank=True, | ||
| on_delete=models.SET_NULL, related_name="assignees") | ||
| on_delete=models.SET_NULL, related_name="+") |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
FYI, I partially fixed it in the PR.
Why do you keep a backward relation for owned tasks but delete such a relation for assigned ones?
Additionally, shouldn't we define a consistent scheme for User <-> Job, User <-> Task, User <-> Project relations?
(e.g., now the User modal still has a backward relation for assigned jobs with the default name; backward relations for assigned and owned projects don't exist; backward relation for owned tasks exists)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Why do you keep a backward relation for owned tasks but delete such a relation for assigned ones?
It wasn't clear to me whether a backwards relation for assigned tasks would be useful or what its name should be (I just knew that the current name wasn't good 🙂), so I figured removing it would be a reasonable option.
Additionally, shouldn't we define a consistent scheme for User <-> Job, User <-> Task, User <-> Project relations?
Yeah, I agree. I didn't even realize that user.jobs is currently the user's assigned jobs. 😵💫
Do you think it's useful to have backwards relations for assigned tasks, jobs, etc.? I see that in your PR you name them assigned_X, but you don't seem to actually be using them.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Okay, having thought about your PR some more, I like your solution for the assignee fields, so I'm going to pause this PR until you complete yours.
6ff1bd7 to
1b70464
Compare
|
Codecov Report✅ All modified and coverable lines are covered by tests. Additional details and impacted files@@ Coverage Diff @@
## develop #9621 +/- ##
===========================================
+ Coverage 82.28% 82.36% +0.08%
===========================================
Files 483 483
Lines 49323 49313 -10
Branches 4132 4132
===========================================
+ Hits 40587 40619 +32
+ Misses 8736 8694 -42
🚀 New features to boost your workflow:
|
…` models * Set `related_query_name` to singular nouns, which matches the Django default (and also some of the existing model fields). * Fix inconsistent `related_name`s in `CloudStorage` fields.
07bc98f to
fca5765
Compare
|
Motivation and context
Set
related_query_nameto singular nouns, which matches the Django default (and also some of the existing model fields).Fix inconsistent
related_names inCloudStoragefields.How has this been tested?
Checklist
developbranch[ ] I have created a changelog fragment[ ] I have updated the documentation accordingly[ ] I have added tests to cover my changes[ ] I have linked related issues (see GitHub docs)License
Feel free to contact the maintainers if that's a concern.