-
Notifications
You must be signed in to change notification settings - Fork 15
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
Miscellaneous cleanup #3
Comments
Regarding parent-child contexts. I've found and also read in other blogs that parent-child context do not perform better. They may be easier to set up but have (or at least had) subtle bugs that requires work-arounds. Performance-wise, they are actually slower, if I remember correctly. One consideration: the child context, when in background queue, doesn't actually save to the persistent store when - For example, if you change object's attributes in the main thread's context after child is created and you perform a fetch in child, do you see the changes in the modified object? Does it depend on whether it's already pushed to main thread's parent? Does it depend on if it's already saved to disk? Do you know answers to all these? I'm using this (parent-child) architecture in Trickster, one of my application. I've had a lot of problems with this. It kinda works now but sometimes it may get an occasional crash when several heavy operations are performed in the background. It's hard to debug this because some of these aspects are not well documented or do not perform according to the documentation. The old method of saving in the background and then merging changes manually is much more straightforward, debugged, and better understood. For reference about the performance of different setups read the following three blog posts: |
|
Regarding |
The
|
@apparentsoft Thanks a lot for the detailed replies! Regarding parent-child contexts... Well, yeah, I was thinking about it a bit more and became pretty unsure about it myself. I'm using this approach in some of my applications and it generally seems to work fine (save for one nasty bug in iOS 5) and simplifies the code a bit. However, I see potential problems with using it together with RAC because of requirement to perform operations in private queues. Your points are also valid. So yeah, I guess it's better like it is now.
That's right. I was trying to say that the name of the latter method may be a bit confusing to some people.
Sorry because I'm still pretty new to ReactiveCocoa, but will this actually work? It seems to me that the receiver signal will just be lost. |
You might be right and
As I understand it, not the signal will be lost, but what the signal sends next. But consider that the signal is just a trigger and you don't care about its value, or you check its value in another reactive chain. In practice, I've not yet used this method. I think it'll work. Perhaps it's a bad approach and |
I just took an example for
And |
I see your point (and my bug). - (RACSignal *)findAll:(NSString *)entityName;
{
NSFetchRequest *fetchRequest = [NSFetchRequest fetchRequestWithEntityName:entityName];
return [self mapReplace:fetchRequest];
} |
Yeah, this one should work. I'm not sure if it's worth its money, though. As you pointed out, |
Maybe it's better to just remove these two methods from the code, then. |
Let's do it! And also the context method renaming part. Actually, I feel like I want to rename |
Well, the idea here is that the main context is really the main context. Yes, it's also the parent, but it should be the real main context. [mainContext performSelector:@selector(mergeChangesFromContextDidSaveNotification:)
onThread:[NSThread mainThread]
withObject:note
waitUntilDone:YES]; |
Hi!
First of all, I wanna say thanks for creating and sharing this cool stuff, I'm looking forward to using it in my projects. And I feel like there are a couple things that could be done to make it even better :)
Here are the points I wanna ask you about:
rcd_merged
signal can be replaced with a signal forNSManagedObjectContextObjectsDidChangeNotification
to serve the similar purpose.+ (NSManagedObjectContext *)context
and+ (NSManagedObjectContext *)currentContext
in theNSManagedObjectContext (ReactiveCoreData)
category are a bit confusing... Perhaps we could just eliminate the former one?- (RACSignal *)findAll:
and- (RACSignal *)findOne:
inRACSignal (ReactiveCoreData)
category ignore the receiver completely and just return new signals... I guess they should be class methods instead?+ (instancetype)insert
and+ (instancetype)insert:
fromNSManagedObject (ReactiveCoreData)
to some other place or maybe remove them completely? They seem like they have nothing to do with ReactiveCocoa stuff :)Let me know what do you think about this. If you are okay with these points, I'm willing to contribute :)
The text was updated successfully, but these errors were encountered: