Official CoreData programming guide
- For relationships, use inverses. See section Inverse relationships from official doc on relationships
Most object relationships are inherently bidirectional. If a Department has a to-many relationship to the Employees who work in a Department, there is an inverse relationship from an Employee to the Department that is to-one. The major exception is a fetched property, which represents a weak one-way relationship—there is no relationship from the destination to the source. The recommended approach is to model relationships in both directions and specify the inverse relationships appropriately.
When creating a deletion rule for a relationship always ask yourself, "What should happen when this model instance is deleted? What should happen to the model on the other end of the relationship?"
Example: You have an employee entity and department entity. In the employee entity you define a one-to-one relationship called "department" that maps to the department entity. In the department entity you define a one-to-many relationship called "employees" to the employee entity. You setup both of these 2 relationships to be the inverse of each other. The delete rule that you setup on "employees" is what will happen when the department entity instance is deleted. What will happen to the employee model instances in that relationship and their links. The delete rule on "department" is what will happen when the employee entity is deleted. What will happen to the department model instance in that relationship and it's link.
If there is at least one object at the relationship destination (employees), do not delete the source object (department).
For example, if you want to remove a department, you must ensure that all the employees in that department are first transferred elsewhere; otherwise, the department cannot be deleted.
Remove the relationship (link) between the objects, but do not delete either object.
This only makes sense if the department relationship for an employee is optional, or if you ensure that you set a new department for each of the employees before the next save operation.
Delete the objects at the destination of the relationship when you delete the source.
For example, if you delete a department, fire all the employees in that department at the same time.
Do nothing to the object at the destination of the relationship.
For example, if you delete a department, leave all the employees as they are, even if they still believe they belong to that department.
The pieces of it:
- The
.xcdatamodelidfile - Setup the stack for the app
- Manually defining the Swift model classes
- Inserting, deleting, fetching.
- Unit testing with CoreData.
- Taget membership: Your app
- Entities inside:
- Entity name: Name of your entity
- Class name: Name of the Swift class that represents this model. I usually copy/paste from the entity name to prevent typos.
- Module: Current Product Module
- Codegen: Manual/none
This revolves around a file, AppCoreDataManager. The file is attached to this gist. We need to create a protocol, CoreDataManager because we will create a separate stack for testing later on.
The AppCoreDataManager is a singleton. All we need to do is load it when the app starts:
@UIApplicationMain
class AppDelegate: UIResponder, UIApplicationDelegate {
func application(_ application: UIApplication, didFinishLaunchingWithOptions launchOptions: [UIApplication.LaunchOptionsKey: Any]?) -> Bool {
AppCoreDataManager.shared.loadStore { error in
if let error = error {
// log the error to crash reporting tool if you use one.
fatalError("CoreData load error \(error.localizedDescription)")
}
// load your ViewController.
}
return true
}
...
}import CoreData
import Foundation
// @objc(CycleModel) // Not needed. Some stackoverflow answers said to use this to solve some problems but I have not needed to use it.
class CycleModel: NSManagedObject, CycleContract {
@NSManaged var cycleNumberRaw: Int16
@NSManaged var quarterNumberRaw: Int16
@NSManaged var ignored: Bool
@NSManaged var started: Date?
@NSManaged var ended: Date?
var cycleNumber: Int {
Int(cycleNumberRaw)
}
var quarterNumber: Int {
Int(quarterNumberRaw)
}
@NSManaged var tasks: [ToDoListTaskModel]? // Model: on delete, deny. For safety reasons, we will only allow a cycle to be deleted if all of the tasks associated with that task are either moved or deleted. This prevents tasks from being deleted by accident.
@nonobjc class func fetchRequest() -> NSFetchRequest<CycleModel> {
NSFetchRequest<CycleModel>(entityName: name)
}
}
extension CycleModel {
static var name: String {
"CycleModel"
}
static func insertFrom(_ vo: CycleVo, context: NSManagedObjectContext) -> CycleModel {
// Using `NSEntityDescription.entity()` for inserting the model instance works. But, I am using `NSEntityDescription.insertNewObject()` because the official Apple CoreData document uses that.
// let model = CycleModel(entity: NSEntityDescription.entity(forEntityName: CycleModel.name, in: context)!, insertInto: context)
let model = NSEntityDescription.insertNewObject(forEntityName: name, into: context) as! CycleModel // swiftlint:disable:this force_cast
model.cycleNumberRaw = Int16(vo.cycleNumber)
model.quarterNumberRaw = Int16(vo.quarterNumber)
model.ignored = vo.ignored
model.started = vo.started
model.ended = vo.ended
model.tasks = nil
return model
}
func toVo() -> CycleVo {
CycleVo(cycleNumber: cycleNumber, quarterNumber: quarterNumber, ignored: ignored, started: started, ended: ended)
}
}Notice that I used "CycleModel" for the static entity name. Some Stackoverflow answers suggest that you use the name of your module as a prefix. Example: "ModuleName.CycleModel". You may need to do this depending on how your project is setup but I found that this did not work for me and leaving it out worked.
I like to use VO struct objects to be deserialized from JSON network calls and displaying in the UI. I like to only use models for the saving to the DB layer and that's it. The less I need to deal with CoreData the less chances of errors.
To finish my example, see the attached file to this gist.
coreDataManager.performBackgroundTask { context in
_ = CycleModel.insertFrom(CycleVo(cycleNumber: 1, quarterNumber: 1, ignored: false, started: Date.yesterday, ended: nil), context: context)
try! context.save()
}coreDataManager.performBackgroundTask { context in
let request: NSFetchRequest<CycleModel> = CycleModel.fetchRequest()
let cycle = try! context.fetch(request)[0]
context.delete(cycle)
try! context.save()
}let request: NSFetchRequest<CycleModel> = CycleModel.fetchRequest()
let cycles = try! coreDataManager.uiContext.fetch(request)First, we need to make sure that we do not run the App's CoreData stack when tests run. That means that we need to make sure that the AppCoreDataManager.loadStore {} does not run when we run tests.
I like to add this to my AppDelegate:
@UIApplicationMain
class AppDelegate: UIResponder, UIApplicationDelegate {
func application(_ application: UIApplication, didFinishLaunchingWithOptions launchOptions: [UIApplication.LaunchOptionsKey: Any]?) -> Bool {
// We must allow running a host app for unit tests so that we can test keychains in our unit tests. So to prevent the appdelegate from running any code, return early and have tests run assuming appdelegate code did not run.
// See: https://github.com/kishikawakatsumi/KeychainAccess/issues/399
if CommandLine.arguments.contains("--unit-testing") {
return true
}
...
}
}Then, I edit my scheme for running tests in XCode. Under Test > Arguments > add an argument --unit-testing. Now your AppDelegate code will not execute.
To unit test, you need a separate CoreData stack. One that is super fast and can erase for us between tests. We want to use in-memory. See the file TestCoreDataManager in this gist for the full file. Add this file to your tests and have it's target membership just be for tests.
To use it, it's quite simple.
import Foundation
import XCTest
import CoreData
@testable import App
class CycleModelTest: XCTestCase {
var coreDataManager: TestCoreDataManager!
override func setUp() {
coreDataManager = TestCoreDataManager()
super.setUp()
}
func test_delete_givenNoTasksForCycle_expectDeleteToSucceed() {
let expectInsert = expectation(description: "Expect to insert")
coreDataManager.performBackgroundTask { context in
_ = CycleModel.insertFrom(CycleVo(cycleNumber: 1, quarterNumber: 1, ignored: false, started: Date.yesterday, ended: nil), context: context)
try! context.save()
expectInsert.fulfill()
}
waitForExpectations(for: [expectInsert])
let expectToDelete = expectation(description: "Expect to delete")
coreDataManager.performBackgroundTask { context in
let request: NSFetchRequest<CycleModel> = CycleModel.fetchRequest()
let cycle = try! context.fetch(request)[0]
context.delete(cycle)
try! context.save()
expectToDelete.fulfill()
}
waitForExpectations(for: [expectToDelete])
let request: NSFetchRequest<CycleModel> = CycleModel.fetchRequest()
let cycles = try! coreDataManager.unsafeContext.fetch(request)
XCTAssertTrue(cycles.isEmpty)
}
}This error was being thrown when I was trying to perform a fetch request: let cycles = try! coreDataManager.uiContext.fetch(CycleModel.fetchRequest()) However, I found that the error message is not actually the error message we should be paying attention to. In XCode, apply a filter in the console for "coredata" to only show log messages for CoreData. You will see errors being thrown which is the root problem that is causing the error we are talking about here.
In the XCode console, I found the error Multiple NSEntityDescriptions claim the NSManagedObject subclass. This is the error we need to fix.
There may be a combination of different problems that cause this error to happen. However, I will share what I did to solve it for me. (1) read the rest of this document to learn about my CoreData stack. If you compare it to yours it may help find other problems and (2) read my fixes below.
The error of Multiple NSEntityDescriptions claim the NSManagedObject subclass was happening when I was performing fetches in my test function: let cycles = try! coreDataManager.uiContext.fetch(CycleModel.fetchRequest()) I figured I am fetching incorrectly then. I felt it was worth the try to try alternatives to filtering. After reading the official Apple docs on fetching in CoreData, I made the following changes:
- I added this function to my
NSManagedObjectsubclass:
class CycleModel: NSManagedObject {
...
@nonobjc class func fetchRequest() -> NSFetchRequest<CycleModel> {
NSFetchRequest<CycleModel>(entityName: "CycleModel")
}
}
- I modified my fetch code in my tests.
let request: NSFetchRequest<CycleModel> = CycleModel.fetchRequest()
let cycles = try! coreDataManager.uiContext.fetch(request)
The CoreData API provides to you a default NSManagedObject.fetchRequest() function which is why I am providing the type for request strictly so that I know the compiler will use the fetchRequest() I made and not the default API provided one.
[error] warning: Multiple NSEntityDescriptions claim the NSManagedObject subclass 'ModelName' so +entity is unable to disambiguate. or, [error] warning: 'ModelName' (0x7f986861cae0) from NSManagedObjectModel (0x7f9868604090) claims 'ModelName'. or, Failed to find a unique match for an NSEntityDescription to a managed object subclass at
Happened because part of the CoreData stack was being loaded multiple times while testing. You know this because if you run the test functions one at a time, they all pass without this error. It only happens if you run 2+ tests that use the CoreData stack at a time.
I used this SO answer to help me fix this problem. If you make the NSManagedObjectModel a singleton so it's only loaded once per all tests. You can load NSPersistentContainer in the setUp() of your test class. In fact, I think loading a new NSPersistentContainer for each test function is what clears the database for you as it's in-memory!
Modify your CoreData stack to make this a singleton.
class TestCoreDataManager: CoreDataManager {
static var sharedMom: NSManagedObjectModel = {
let modelURL = Bundle(for: AppCoreDataManager.self).url(forResource: AppCoreDataManager.nameOfModelFile, withExtension: "momd")!
return NSManagedObjectModel(contentsOf: modelURL)!
}()
let persistentContainerQueue = OperationQueue() // make a queue for performing write operations to avoid conflicts with multiple writes at the same time from different contexts.
static let nameOfModelFile = AppCoreDataManager.nameOfModelFile
private let threadUtil: ThreadUtil = AppThreadUtil()
private let persistentContainer: NSPersistentContainer
init() {
let persistentStoreDescription = NSPersistentStoreDescription()
persistentStoreDescription.type = NSInMemoryStoreType
let container = NSPersistentContainer(name: AppCoreDataManager.nameOfModelFile, managedObjectModel: TestCoreDataManager.sharedMom)
container.persistentStoreDescriptions = [persistentStoreDescription]
container.loadPersistentStores { _, error in
if let error = error as NSError? {
fatalError("Unresolved error \(error), \(error.userInfo)")
}
}
self.persistentContainer = container
}
...
}
There are some other SO questions 1 and many of them share the same pattern where the error only happens for unit tests and incorporating singletons fixes the issue. However, some of those people's CoreData stack is different then mine so it was difficult to use those answers.
This SO answer also helped improve my use of CoreData. I made breakpoints in my test code to see what line of code made this error show up. I found that this error was only happening when inserting new models into the DB. From that SO answer, I modified my insert code from: let model = CycleModel(context: context) to let model = CycleModel(entity: NSEntityDescription.entity(forEntityName: CycleModel.name, in: context)!, insertInto: context). I guess using NSEntityDescription is more explicit and lowers the chance of errors from happening in your app. After doing this 1 line of code change, I encountered a new error: executeFetchRequest:error: A fetch request must have an entity. Read about this error in this document. I outline it in here.
Help from this SO answer fixed that problem right away. I added this code:
sharedMom.entities.forEach { (description) in
print("[COREDATA] entity: \(description.name!)")
}
self.persistentContainer.managedObjectModel.entities.forEach { (des) in
print("[COREDATA] container entity: \(des.name!)")
}
to my test CoreData stack after creating the persistentContainer instance. It was at this point that I realized I had a typo in my entity name in the .xcdatamodelid file in XCode...I edited the entity name and that error was fixed.
This is usually part of your CoreData setup. In your .xcdatamodelid file in XCode you may have entered in the wrong model name, the wrong module, etc. It is usually a quick fix. This SO question is good inspiration to a few ways you can fix this.