-
Notifications
You must be signed in to change notification settings - Fork 1.1k
Remove legacy Core Data stack #19770
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
Generated by 🚫 dangerJS |
You can test the changes in WordPress from this Pull Request by:
|
You can test the changes in Jetpack from this Pull Request by:
|
| startupEvent.add(error: error) | ||
| } | ||
|
|
||
| // TODO: The original Objective C implement calls `loadPersistentStores` again here, but throws an exception regardless the result. |
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 can certainly keep the code that calls loadPersistentStores again, but I don't see how this additional call is necessary, did I miss anything?
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 don't see how this additional call is necessary
Me neither.
| #import "PostService.h" | ||
| #import "TodayExtensionService.h" | ||
| #import "ContextManager.h" | ||
| #import "CoreDataStack.h" |
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 looks like this import is duplicated from line 5.
| #import "CoreDataStack.h" |
| import Foundation | ||
| import CoreData | ||
|
|
||
| ///A constant representing the current version of the data model. |
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.
| ///A constant representing the current version of the data model. | |
| /// A constant representing the current version of the data model. |
| @@ -1,5 +1,7 @@ | |||
| import XCTest | |||
|
|
|||
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: Does this empty line signifies something or can we remove it?
| /// Ensure that the `context`'s concurrency type is not `confinementConcurrencyType`, since it will crash if `perform` or `performAndWait` is called. | ||
| guard context.concurrencyType == .mainQueueConcurrencyType || context.concurrencyType == .privateQueueConcurrencyType 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.
The comment says we want to check that the context != x. The code checks that == y || == z.
The difference might be important. I think it would be good to keep code and comment consistent.
Also, nitpick, /// will result in a documentation header comment, but that doesn't apply for this kind of comment since it's not on a definition but on a guard statement.
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.
The original PR chose to not reference the deprecated confinementConcurrencyType to avoid a warning.
| block() | ||
| return |
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.
Is running the given block a fallback mechanism to keep the app working without having to do deal with the runtime complexity of handling an error if the context is incorrect?
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.
Calling performBlock on a context whose concurrency type is confinement crashes, see the original PR for context.
| startupEvent.add(error: error) | ||
| } | ||
|
|
||
| // TODO: The original Objective C implement calls `loadPersistentStores` again here, but throws an exception regardless the result. |
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 don't see how this additional call is necessary
Me neither.
For breadcrumbs, see #19433 where we switched to use the new Core Data stack via feature toogle. That code has been running in production for more than a month. |
Changes
Given there is no major issue found in the
ContainerContextFactory, we can now migrate to use the new Core Data stack fully. This PR removes the legacy Core Data stack (LegacyContextFactory) and mergeContainerContextFactoryintoContextManager.This PR also translates
ContextManagerto Swift, so that we can use all the nice things Swift provides us in the very foundation of our Core Data stack.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.txtif necessary.