-
Notifications
You must be signed in to change notification settings - Fork 1
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
[MINT-3222] Milestone Solution Link #1541
[MINT-3222] Milestone Solution Link #1541
Conversation
pkg/sqlqueries/SQL/mto/solution/get_by_model_plan_id_and_common_solution_key_LOADER.sql
Outdated
Show resolved
Hide resolved
pkg/sqlqueries/SQL/mto/milestone/create_milestone_solution_link.sql
Outdated
Show resolved
Hide resolved
…ns_when_adding_common_milestone # Conflicts: # pkg/graph/resolvers/mto_milestone.go
…ns_when_adding_common_milestone
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.
Overall this looks good! I think the new UPSERT
-style resolver reads cleanly!
There's a few pieces of code I think we can nix, but the main thing to look at is probably adding the JOIN to the create-solution (allowing conflicts) query
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.
Thanks @OddTomBrooks , I think that this looks good overall! I left a few comments, mostly around todos for future enhancement and minor changes.
I think we can get this to be a bit more efficient, but I think a TODO could be appropriate for the sake of this PR.
pkg/sqlqueries/SQL/mto/milestone/create_milestone_solution_link.sql
Outdated
Show resolved
Hide resolved
pkg/storage/mto_milestone.go
Outdated
|
||
arg := map[string]interface{}{"milestone_id": milestoneID} | ||
|
||
returned, procErr := sqlutils.SelectProcedure[models.MTOMilestoneSolutionLink](np, sqlqueries.MTOMilestone.GetMilestoneSolutionLinksByMilestoneID, arg) |
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.
I'm not sure that you need to fetch links explicitly here, I think you can validate by fetching linked solutions instead. We don't really need to fetch links, just the solutions / milestones themselves.
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.
You're right. I thought about this quite a bit yesterday. In an ideal world our store would be mocked and we could do flow assertions, but the only way to validate the linking table is functioning as expected was to create a simple fetch. I feel like for unit testing / validation purposes having a fetch method is worthwhile.
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.
sounds good, that works for me! We have a separate ticket for fetching linked solutions, we could use that later if we want, I'm also fine just keeping it.
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.
Related to earlier conversation, I think this might not be needed, instead we can just fetch the actual milestone / solution that is linked.
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.
See above comment for continued discussion, I will apply the resolution here as well
@@ -390,6 +390,24 @@ func (suite *ResolverSuite) createDefaultTestAnalyzedAudit(mp *models.ModelPlan, | |||
|
|||
} | |||
|
|||
func (suite *ResolverSuite) createMilestoneCommon( |
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.
@OddTomBrooks, this is fine here, wanted to see what you thought about moving to the mto_milestone test file instead though? I think it might feel a bit better organizationally, though we aren't doing this now.
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.
I think this is worth a higher level discussion on how we want to organize the logic in our test suite, let's have a chat after standup today
…ns_when_adding_common_milestone # Conflicts: # MINT.postman_collection.json # pkg/graph/generated/generated.go # pkg/graph/schema/types/mto_milestone.graphql
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.
Thanks for making these changes @OddTomBrooks, it looks good.
I think that git did something weird with some files (eg, it's showing you adding the new categories resolver in GQL). I don't think it matters functionally though
This happened when I merged in from the base branch. I took the incoming logic, not sure why it would be an addition. Maybe the formatting is off or something. |
MINT-3222
Description
How to test this change
scripts/dev test:go
runs successfullyPR Author Checklist
PR Reviewer Guidelines