Move xcdatamodeld into WordPressData - #24166
Closed
mokagio wants to merge 26 commits into
Closed
Conversation
Collaborator
Generated by 🚫 Danger |
mokagio
commented
Mar 7, 2025
| <relationship name="blog" optional="YES" maxCount="1" deletionRule="Nullify" destinationEntity="Blog" inverseName="authors" inverseEntity="Blog" syncable="YES"/> | ||
| </entity> | ||
| <entity name="BloggingPrompt" representedClassName=".BloggingPrompt" syncable="YES"> | ||
| <entity name="BloggingPrompt" representedClassName="WordPressData.BloggingPrompt" syncable="YES"> |
mokagio
commented
Mar 7, 2025
Comment on lines
+3
to
+27
| public let modelURL: URL = { | ||
| guard let url = Bundle.module.url(forResource: "WordPress", withExtension: "momd") else { | ||
| fatalError("Cannot find model file.") | ||
| } | ||
| return url | ||
| }() | ||
|
|
||
| public func urlForModel(name: String, in directory: String?) -> URL? { | ||
| let bundle = Bundle(for: TemporaryDummyClassToPickUpModule.self) | ||
| var url = bundle.url(forResource: name, withExtension: "mom", subdirectory: directory) | ||
|
|
||
| if url != nil { | ||
| return url | ||
| } | ||
|
|
||
| let momdPaths = bundle.paths(forResourcesOfType: "momd", inDirectory: directory) | ||
| momdPaths.forEach { (path) in | ||
| if url != nil { | ||
| return | ||
| } | ||
| url = bundle.url(forResource: name, withExtension: "mom", subdirectory: URL(fileURLWithPath: path).lastPathComponent) | ||
| } | ||
|
|
||
| return url | ||
| } |
Contributor
Author
There was a problem hiding this comment.
These free functions should go into an object at some point.
It was just simpler to chuck them in here at this stage while I figure things out.
Also, I'd like to think there will be no need to have them public once all the types involved in setting up the Core Data stack have been moved.
Contributor
|
| App Name | Jetpack Alpha |
|
| Configuration | Release-Alpha | |
| Build Number | pr24166-43bb76a | |
| Version | 25.8 | |
| Bundle ID | com.jetpack.alpha | |
| Commit | 43bb76a | |
| App Center Build | jetpack-installable-builds #10655 |
Contributor
|
| App Name | WordPress Alpha |
|
| Configuration | Release-Alpha | |
| Build Number | pr24166-43bb76a | |
| Version | 25.8 | |
| Bundle ID | org.wordpress.alpha | |
| Commit | 43bb76a | |
| App Center Build | WPiOS - One-Offs #11624 |
Contributor
|
Have you tried overriding an Objective-C class name for the managed objects written in Swift? |
mokagio
force-pushed
the
mokagio/share-classNameWithoutNamespaces
branch
from
March 7, 2025 20:56
81890b9 to
57a9e60
Compare
Base automatically changed from
mokagio/share-classNameWithoutNamespaces
to
trunk
March 7, 2025 21:51
Contributor
Author
@kean yes I did try that. I removed it from the code pushed here because it did not make any difference |
mokagio
force-pushed
the
mokagio/move-xcdatamodeld-to-wordpressdata
branch
from
March 11, 2025 00:42
b94d69d to
e1eb0b3
Compare
This is so the diff is neater next when moving it to WordPressShared
Turned out there needed to be move access control changes than those done in the previous commit...
We'll obviously have to deal with this at some point, but doing it while moving the files from the app targets to the new module is not the right time.
Swift-ier + Saves making `sharedInstance()` public when migrating
Not the best approach, but fine because the property is for testing only.
Currently unused, but we'll use them soon when moving more of the Objective-C models.
We need it in a dedicated package because the Objective-C implementation does not use ARC. Therefore, we need to use the `-fno-objc-arc` compiler setting. But such a setting should be applied sparingly so instead of blanket using it in an existing Objective-C package like WordPressSharedObjC, we use it surgically just for this file.
This is to decouple the Objective-C implementation from knowing about components (i.e. `ContextManager`) in the Swift layer.
mokagio
added a commit
that referenced
this pull request
Mar 12, 2025
To much Objective-C code using logic implemented elsewhere in Swift for us to be able to move the files in two separate Objective-C- and Swift- only packages. Refer to #24166 as an experiment for this that shows the various build failure that even a partial attempt at moving some files results in.
mokagio
added a commit
that referenced
this pull request
Mar 13, 2025
To much Objective-C code using logic implemented elsewhere in Swift for us to be able to move the files in two separate Objective-C- and Swift- only packages. Refer to #24166 as an experiment for this that shows the various build failure that even a partial attempt at moving some files results in.
mokagio
added a commit
that referenced
this pull request
Mar 14, 2025
To much Objective-C code using logic implemented elsewhere in Swift for us to be able to move the files in two separate Objective-C- and Swift- only packages. Refer to #24166 as an experiment for this that shows the various build failure that even a partial attempt at moving some files results in.
mokagio
added a commit
that referenced
this pull request
Mar 17, 2025
To much Objective-C code using logic implemented elsewhere in Swift for us to be able to move the files in two separate Objective-C- and Swift- only packages. Refer to #24166 as an experiment for this that shows the various build failure that even a partial attempt at moving some files results in.
mokagio
added a commit
that referenced
this pull request
Mar 18, 2025
To much Objective-C code using logic implemented elsewhere in Swift for us to be able to move the files in two separate Objective-C- and Swift- only packages. Refer to #24166 as an experiment for this that shows the various build failure that even a partial attempt at moving some files results in.
Contributor
Author
|
Closing in favor of #24242 |
mokagio
added a commit
that referenced
this pull request
Mar 19, 2025
To much Objective-C code using logic implemented elsewhere in Swift for us to be able to move the files in two separate Objective-C- and Swift- only packages. Refer to #24166 as an experiment for this that shows the various build failure that even a partial attempt at moving some files results in.
mokagio
added a commit
that referenced
this pull request
Mar 20, 2025
To much Objective-C code using logic implemented elsewhere in Swift for us to be able to move the files in two separate Objective-C- and Swift- only packages. Refer to #24166 as an experiment for this that shows the various build failure that even a partial attempt at moving some files results in.
mokagio
added a commit
that referenced
this pull request
Mar 24, 2025
To much Objective-C code using logic implemented elsewhere in Swift for us to be able to move the files in two separate Objective-C- and Swift- only packages. Refer to #24166 as an experiment for this that shows the various build failure that even a partial attempt at moving some files results in.
mokagio
added a commit
that referenced
this pull request
Mar 25, 2025
To much Objective-C code using logic implemented elsewhere in Swift for us to be able to move the files in two separate Objective-C- and Swift- only packages. Refer to #24166 as an experiment for this that shows the various build failure that even a partial attempt at moving some files results in.
mokagio
added a commit
that referenced
this pull request
Mar 25, 2025
To much Objective-C code using logic implemented elsewhere in Swift for us to be able to move the files in two separate Objective-C- and Swift- only packages. Refer to #24166 as an experiment for this that shows the various build failure that even a partial attempt at moving some files results in.
mokagio
added a commit
that referenced
this pull request
Mar 25, 2025
To much Objective-C code using logic implemented elsewhere in Swift for us to be able to move the files in two separate Objective-C- and Swift- only packages. Refer to #24166 as an experiment for this that shows the various build failure that even a partial attempt at moving some files results in.
mokagio
added a commit
that referenced
this pull request
Mar 26, 2025
To much Objective-C code using logic implemented elsewhere in Swift for us to be able to move the files in two separate Objective-C- and Swift- only packages. Refer to #24166 as an experiment for this that shows the various build failure that even a partial attempt at moving some files results in.
mokagio
added a commit
that referenced
this pull request
Mar 27, 2025
To much Objective-C code using logic implemented elsewhere in Swift for us to be able to move the files in two separate Objective-C- and Swift- only packages. Refer to #24166 as an experiment for this that shows the various build failure that even a partial attempt at moving some files results in.
mokagio
added a commit
that referenced
this pull request
Mar 27, 2025
To much Objective-C code using logic implemented elsewhere in Swift for us to be able to move the files in two separate Objective-C- and Swift- only packages. Refer to #24166 as an experiment for this that shows the various build failure that even a partial attempt at moving some files results in.
mokagio
added a commit
that referenced
this pull request
Mar 27, 2025
To much Objective-C code using logic implemented elsewhere in Swift for us to be able to move the files in two separate Objective-C- and Swift- only packages. Refer to #24166 as an experiment for this that shows the various build failure that even a partial attempt at moving some files results in.
mokagio
added a commit
that referenced
this pull request
Mar 28, 2025
To much Objective-C code using logic implemented elsewhere in Swift for us to be able to move the files in two separate Objective-C- and Swift- only packages. Refer to #24166 as an experiment for this that shows the various build failure that even a partial attempt at moving some files results in.
mokagio
added a commit
that referenced
this pull request
Mar 28, 2025
To much Objective-C code using logic implemented elsewhere in Swift for us to be able to move the files in two separate Objective-C- and Swift- only packages. Refer to #24166 as an experiment for this that shows the various build failure that even a partial attempt at moving some files results in.
mokagio
added a commit
that referenced
this pull request
Mar 28, 2025
To much Objective-C code using logic implemented elsewhere in Swift for us to be able to move the files in two separate Objective-C- and Swift- only packages. Refer to #24166 as an experiment for this that shows the various build failure that even a partial attempt at moving some files results in.
mokagio
added a commit
that referenced
this pull request
Mar 30, 2025
To much Objective-C code using logic implemented elsewhere in Swift for us to be able to move the files in two separate Objective-C- and Swift- only packages. Refer to #24166 as an experiment for this that shows the various build failure that even a partial attempt at moving some files results in.
mokagio
added a commit
that referenced
this pull request
Mar 31, 2025
To much Objective-C code using logic implemented elsewhere in Swift for us to be able to move the files in two separate Objective-C- and Swift- only packages. Refer to #24166 as an experiment for this that shows the various build failure that even a partial attempt at moving some files results in.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.




Part of #24165
Note
As I try to move more model files, I keep pulling at the intricate dependencies that grew in the codebase.
I'll be leaving comments in the diff as starting point for code to extract in order to enable this PR.
Note
Work in Progress. So far:
xcdatamodeldfolder into the module and updated the code that referenced its URL to read it from the moduleBloggingPrompt(apparently the first model to load at runtime). The error was withFatal error: NSArray element failed to match the Swift Array Element type . Expected BloggingPrompt got NSManagedObject.BloggingPromptto WordPressDataFatal error: NSArray element failed to match the Swift Array Element type . Expected BloggingPrompt got NSManagedObjectI don't like this solution because it would require editing the schema for each model. Besides, the compiler (or whichever piece is involved in going from the schema to the binary) should be able to inject the correct module name without hardcoding.
Leaving this up as a draft so that others can look at it.
The next thing I'll try will be to move more of the components involved in making the Core Data fetch request, the
NSManagedObjectContextin particular, and see if it gets the namespace resolution to work without hardcoding.Fixes #
To test:
Regression Notes
Potential unintended areas of impact
What I did to test those areas of impact (or what existing automated tests I relied on)
What automated tests I added (or what prevented me from doing so)
PR submission checklist:
RELEASE-NOTES.txtif necessary.Testing checklist: