-
Notifications
You must be signed in to change notification settings - Fork 18
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
refactor: Add caching to KnoraGroupRepo (DEV-3311) #3204
Conversation
Remove last modfying functions from GroupResponder and make group repo extend CachingRepository
1fc71fa
to
26cc439
Compare
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.
Looks good, thanks!
groupAndProject <- auth.ensureSystemAdminOrProjectAdminOfGroup(user, iri) | ||
(group, _) = groupAndProject | ||
internal <- knoraGroupService | ||
.updateGroupStatus(group, request.status) | ||
.flatMap(groupService.toGroup) | ||
.map(GroupGetResponseADM.apply) |
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.
nitpick: not sure if it makes sense to have for-comprehensions if we use map and flatmap in them; or vice versa, if it makes sense to use map and flatmap, if we're in a for-comprehension
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.
IMO this still reads better than chaining it all in one go. These lines could be also extracted to separate private methods, especially they are reused in deleteGroup
methods below.
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 am totally ok to mix for comprehension with a flatmap here and there,
- I am totally ok with a chain of flatmaps here and there
- I had my reason of why the internal has become its own name and the intermediate transformative results where in a chain of map/flatMap for my personal preference of making it clear that toGroup and Foo.apply are simply transformations of intermediate unimportant results.
- I have extracted the code duplication in a separate method and introduced intermediate result name due to popular demand. b247906
TBH, I find this kind of discussion exhausting and have a different preference for readability.
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.
It does look better with the flatMap refactored.
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. Please find my minor suggestions below:
webapi/src/main/scala/org/knora/webapi/routing/Authenticator.scala
Outdated
Show resolved
Hide resolved
webapi/src/main/scala/org/knora/webapi/routing/Authenticator.scala
Outdated
Show resolved
Hide resolved
groupAndProject <- auth.ensureSystemAdminOrProjectAdminOfGroup(user, iri) | ||
(group, _) = groupAndProject | ||
internal <- knoraGroupService | ||
.updateGroupStatus(group, request.status) | ||
.flatMap(groupService.toGroup) | ||
.map(GroupGetResponseADM.apply) |
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.
IMO this still reads better than chaining it all in one go. These lines could be also extracted to separate private methods, especially they are reused in deleteGroup
methods below.
…cala Co-authored-by: Marcin Procyk <[email protected]>
…cala Co-authored-by: Marcin Procyk <[email protected]>
Pull Request Checklist
Task Description/Number
Issue Number: DEV-
PR Type
Basic requirements for bug fixes and features
Does this PR introduce a breaking change?
Does this PR change client-test-data?