-
Notifications
You must be signed in to change notification settings - Fork 1.1k
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
Remove context from a few service types #20010
Conversation
You can test the changes in WordPress from this Pull Request by:
|
You can test the changes in Jetpack from this Pull Request by:
|
d2f1d2a
to
e667bcb
Compare
@@ -115,8 +111,7 @@ class SiteManagementServiceTests: CoreDataTestCase { | |||
mockRemoteService.successBlockPassedIn?() | |||
waitForExpectations(timeout: 2, handler: nil) | |||
|
|||
let shouldBeRemoved = try? context.existingObject(with: blogObjectID) | |||
XCTAssertFalse(shouldBeRemoved != nil, "Blog was not removed") | |||
try XCTAssertEqual(context.count(for: Blog.fetchRequest()), 0) |
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.
Changed this assertion here because the blog will exist in the context
until context.save()
is called. Using NSFetchRequest
is a more accurate way to check if the object is deleted from the database.
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 👍
Do you know whether there are more of this kind of tests that we should consider upgrading (in a dedicated all-in-one PR)?
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, this is the first time I ran into this kind of issue, maybe I'll find more? I can only notice them if I happen to look at the test case or the test case fails during development. 😄
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.
Only nitpicks 👍
suggestion = NSEntityDescription.insertNewObject(forEntityName: ReaderSearchSuggestion.classNameWithoutNamespaces(), | ||
into: managedObjectContext) as? ReaderSearchSuggestion | ||
suggestion?.searchPhrase = phrase | ||
self.coreDataStack.performAndSave { context in |
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: Is it necessary to access coreDataStack
from self
here?
self.coreDataStack.performAndSave { context in | |
coreDataStack.performAndSave { context in |
@@ -30,71 +40,35 @@ import CocoaLumberjack | |||
/// | |||
/// - Returns: A matching search phrase or nil. | |||
/// | |||
@objc func findSuggestionForPhrase(_ phrase: String) -> ReaderSearchSuggestion? { | |||
private func findSuggestionForPhrase(_ phrase: String, in context: NSManagedObjectContext) -> ReaderSearchSuggestion? { |
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 / Out of scope convention question:
This method use findSuggestionForPhrase(_ phrase: String, ...
a similar method in a different file from this diff use lookup(withBlogID blogID: String, ...
. The style of the two is inconsistent.
I personally prefer the latter, but I think the Swift API Design Guidelines would recommend using the former, as the argument is part of a prepositional phrase.
"For" and "with" are both prepositions, ChatGPT told me so:
To be honest, I feel like breaking from the guidelines in this case. I find more value in not having to think whether to name the first parameter or not vs. using what might be better English grammar in the API names.
What do you think?
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 Swift API Design Guidelines would recommend using the former
If I understand it correctly, using the former is a case of exception where there are two or more arguments? i.e. findSuggestionFor(phrase: "hello", author: "Tony")
The signature findSuggestion(forPhrase: "hello", in: context)
looks pretty nature to me, so I've changed it in 754dae1
var suggestions = [ReaderSearchSuggestion]() | ||
do { | ||
suggestions = try context.fetch(fetchRequest) as! [ReaderSearchSuggestion] | ||
} catch let error as NSError { | ||
DDLogError("Error fetching search suggestion : \(error.localizedDescription)") | ||
} | ||
for suggestion in suggestions { | ||
context.delete(suggestion) | ||
} |
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: Have you considered moving the for
loop inside the do catch
to avoid declaring a var
?
var suggestions = [ReaderSearchSuggestion]() | |
do { | |
suggestions = try context.fetch(fetchRequest) as! [ReaderSearchSuggestion] | |
} catch let error as NSError { | |
DDLogError("Error fetching search suggestion : \(error.localizedDescription)") | |
} | |
for suggestion in suggestions { | |
context.delete(suggestion) | |
} | |
do { | |
try (context.fetch(fetchRequest) as! [ReaderSearchSuggestion]).forEach { context.delete($0) } | |
} catch let error as NSError { | |
DDLogError("Error fetching search suggestion : \(error.localizedDescription)") | |
} |
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.
👍 Addressed in 2b5f7d0
roleService.fetchRoles(success: {_ in | ||
roleService.fetchRoles(success: { |
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.
💅 👍
guard let blog = blog, | ||
let service = RoleService(blog: blog, context: viewContext) else { | ||
return nil | ||
guard let blog = blog else { |
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 was going to suggest guard let blog else
but I got annoyed at myself for being so pedantic about things that could be automated...
SwiftLint supports this, I should add the check to our https://github.com/Automattic/swiftlint-config and integrate it here...
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.
No worries. It's always good to have cleaner code. Updated in 4412706
@@ -115,8 +111,7 @@ class SiteManagementServiceTests: CoreDataTestCase { | |||
mockRemoteService.successBlockPassedIn?() | |||
waitForExpectations(timeout: 2, handler: nil) | |||
|
|||
let shouldBeRemoved = try? context.existingObject(with: blogObjectID) | |||
XCTAssertFalse(shouldBeRemoved != nil, "Blog was not removed") | |||
try XCTAssertEqual(context.count(for: Blog.fetchRequest()), 0) |
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 👍
Do you know whether there are more of this kind of tests that we should consider upgrading (in a dedicated all-in-one PR)?
Co-authored-by: Gio Lodi <gio.lodi@automattic.com>
Use
CoreDataStack
instead ofNSManagedObjectContext
in a few service types. See the "Issue" and "Proposal" sections of #19893 for rational behind this change.Regression Notes
Potential unintended areas of impact
None
What I did to test those areas of impact (or what existing automated tests I relied on)
None
What automated tests I added (or what prevented me from doing so)
None
PR submission checklist:
RELEASE-NOTES.txt
if necessary.