-
Notifications
You must be signed in to change notification settings - Fork 76
Conversation
*/ | ||
static public func newInContext(context: NSManagedObjectContext) -> Self { | ||
return NSEntityDescription.insertNewObjectForEntityForName(entityName, inManagedObjectContext: context) as! Self | ||
} |
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've had success with this as an initializer:
extension CoreDataModelable {
static func entityInContext(context: NSManagedObjectContext) -> NSEntityDescription! {
guard let entity = NSEntityDescription.entityForName(entityName, inManagedObjectContext: context) else {
assertionFailure("Entity named \(entityName) doesn't exist. Fix the entity description or naming of \(Self.self).")
return nil
}
return entity
}
}
extension CoreDataModelable where Self: NSManagedObject {
init(managedObjectContext context: NSManagedObjectContext) {
self.init(entity: Self.entityInContext(context), insertIntoManagedObjectContext: context)
}
}
*/ | ||
static public func findFirst(predicate: NSPredicate?, context: NSManagedObjectContext) -> Self? { | ||
let fetchRequest = NSFetchRequest(entityName: entityName) | ||
fetchRequest.predicate = predicate |
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.
Add fetchRequest.fetchLimit = 1
here to improve performance.
Rather than have the test case conform to EntityMonitorDelegate there are two distinct classes for each test type. This also shows an example of having EntityMonitors for two different Entity types.
This was an early attempt at triggering the MOC to observe object changes. Earlier addition of moc.processPendingChanges() is much more explicit and deterministic.
This ensures that if an entity is not in a supplied context it will assert with a useful failure rather than failing to force cast.
Including subentries is unnecessary since we're deleting objects. Also adding a note on how we could improve the performance using a batch delete request.
Limiting the batch and fetch size to a single result and returning the object already faulted
Updated based on all the comments. @lyricsboy and @zwaldowski want to take another pass? thanks. |
import CoreData | ||
import CoreDataStack | ||
|
||
var insertExpectation: XCTestExpectation! |
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.
Would prefer to see these as instance variables and passed through initializers to the delegate classes.
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.
Yeah I considered that but that will not work for the way expectations are setup for the OnChange notification tests.
They need to be setup and waited on in a serial fashion so they cannot be setup in the delegate's initializer.
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 see what you mean now. We can proceed without this change.
Add type safe Entity Monitor
EntityMonitor observes a given NSManagedObjectContext for Updates, Deletes, and Inserts of a specific entity type. An optional filter predicate can also be added.
This can be used in place of an NSFetchedResultsController when you are not binding your data to an UITableViewController.