Refs #19765 (comment)
Currently, when saving a post in the Reader, a didSave hook is implemented on ReaderPost to update the parent object, ReaderCard:
|
- (void) didSave { |
|
[super didSave]; |
|
|
|
// A ReaderCard can have either a post, or a list of topics, but not both. |
|
// Since this card has a post, we can confidently set `topics` to NULL. |
|
if ([self respondsToSelector:@selector(card)] && self.card.count > 0) { |
|
self.card.allObjects[0].topics = NULL; |
|
[[ContextManager sharedInstance] saveContext:self.managedObjectContext]; |
|
} |
|
} |
As quoted above, the didSave method made another save call to ContextManager, effectively double-saving every time a post is saved. This can make Core Data operations slightly less visible, and might introduce side effects (i.e., the issue described in #19765). As an idea, we can look into moving this part of the logic to the post-saving logic described in #19765 (review).
Refs #19765 (comment)
Currently, when saving a post in the Reader, a
didSavehook is implemented onReaderPostto update the parent object,ReaderCard:WordPress-iOS/WordPress/Classes/Models/ReaderPost.m
Lines 513 to 522 in be75d66
As quoted above, the
didSavemethod made anothersavecall toContextManager, effectively double-saving every time a post is saved. This can make Core Data operations slightly less visible, and might introduce side effects (i.e., the issue described in #19765). As an idea, we can look into moving this part of the logic to the post-saving logic described in #19765 (review).