-
Notifications
You must be signed in to change notification settings - Fork 73
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
Fixes #22552: General improvements on Directive compliance API #4720
Conversation
for { | ||
time_0 <- currentTimeMillis | ||
nodeIds <- nodeConfigService.findNodesApplyingDirective(directiveId) | ||
rules <- rulesRepo.getAll() |
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 don't use the rules
Commit modified |
b7e6717
to
0445d2f
Compare
Commit modified |
f00c9bd
to
d3f10bf
Compare
Commit modified |
1 similar comment
Commit modified |
d3f10bf
to
90a109e
Compare
Commit modified |
90a109e
to
1cd1f45
Compare
Commit modified |
1cd1f45
to
f54d14b
Compare
Commit modified |
f54d14b
to
fbd54ab
Compare
Commit modified |
fbd54ab
to
2030977
Compare
Commit modified |
2030977
to
2efc650
Compare
Commit modified |
2efc650
to
e1773a8
Compare
Commit modified |
e1773a8
to
efc8397
Compare
Commit modified |
efc8397
to
3706d43
Compare
* only limited on the nodeIds in parameter (used when cache is incomplete) | ||
*/ | ||
def findCurrentNodeIdsForDirective(ruleId: DirectiveId, nodeIds: Set[NodeId]): IOResult[Set[NodeId]] | ||
def findCurrentNodeIdsForDirective(ruleId: DirectiveId): IOResult[Set[NodeId]] |
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 should not use the same function name for different signatures, it creates problems latter on (inference, refactoring, search not working as expected, etc).
At least, each and every time I thought it was a good idea, I got bitten down the path latter on
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.
Actually, given the code it could be that nodeIds
is an option (or have the semantic "if set is empty, ignore id") and just add the and
fragment when it's not empty
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.
What is complex is that to keep the current behaviour:
If some nodes ids => Make the request with a where condition on nodeIds
If none => Make the request without where on node ids
If Some empty set => Don't make request
I'm ok that None and some(Empty) makes sense to not have the and So i need to look the semantic of the empty Set here
And yes i would totally love rewriting this query using more doobie fragments and tools
So i may do another PR to improve this
select distinct nodeid from nodeconfigurations | ||
where enddate is null and configuration like ${"%" + directiveId.serialize + "%"} | ||
""".query[NodeId].to[Set].transact(xa)) | ||
} |
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.
can you factor out the common bit? I think I saw you use something for and part somewhere
(if (groupsComponents.isEmpty) { | ||
Nil | ||
} else { | ||
val bidule = groupsComponents.flatMap { case (nodeId, c) => c.subComponents.map(sub => (nodeId, sub)) } |
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.
:)
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 the bidule was already there .... (but it was already me)
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 would love some unit tests for findDirectiveNodeStatusReports
and there is a bit of code to factor out, but it's small compared to the PR. My tests on dev data seems ok.
So you can merge it like that so that we have a shippable rudder next week, and add unit test along the way.
Commit modified |
3706d43
to
493dc54
Compare
OK, merging this PR |
https://issues.rudder.io/issues/22552