jksk / nlcoredata Goto Github PK
View Code? Open in Web Editor NEWLibrary that wraps Core Data for iOS for easier and more readable operations.
License: MIT License
Library that wraps Core Data for iOS for easier and more readable operations.
License: MIT License
What do you think about this category? https://gist.github.com/buh/6643457
Hi there,
I try to fetch a single object from my database by using this code:
User* user = [User fetchSingleWithPredicate: nil];
But I got the error No known class method for selector 'fetchSingleWithPredicate:'
Any ideas how to fix this? It's an generated object from mogenerator.
Crash : NSPersistentStoreCoordinator has no persistent stores. It cannot perform a save operation.
NSManagedObjectContext+NLCoreData.m line 48
-[NSManagedObjectContext(NLCoreData) save]
15
NSManagedObjectContext+NLCoreData.m line 65
-[NSManagedObjectContext(NLCoreData) saveNested]
16
NSManagedObjectContext+NLCoreData.m line 77
__48-[NSManagedObjectContext(NLCoreData) saveNested]_block_invoke
17
CoreData
developerSubmittedBlockToNSManagedObjectContextPerform + 180
20
CoreData
-[NSManagedObjectContext performBlockAndWait:] + 182
21
NSManagedObjectContext+NLCoreData.m line 75
-[NSManagedObjectContext(NLCoreData) saveNested]
In [NSManagedObject deleteWithRequest:context:] you have
NSFetchRequest* request = [NSFetchRequest fetchRequestWithEntity:[self class] >> context:context];
if (block)
block(request);[request setIncludesPropertyValues:NO];
[request setIncludesSubentities:NO];...
This order makes it impossible to override the includesSubentities property
in the request block. Therefore I think a better way would be to call the block after setting the properties.
BTW: [request setIncludesSubentities:NO] is also being called in [NSFetchRequest fetchRequestWithEntity:context:], which is being called on the first line.
Found this issue when debuging CoreData RULES
Multithreading_Violation_AllThatIsLeftToUsIsHonor , causing crash app in method
- (BOOL)saveNested;
[NSFetchRequest fetchRequestWithEntity:context:] sets includesPropertyValues to NO, which is non default value. This makes the default fetching (and also counting and deleting) behavior unexpected.
I think that the right way is not to modify includesPropertyValues and let the user to set the property if he desires so. I know that I can switch it back to YES, but I have to use the block variants of the methods, which complicates my code unnecessarily.
If you are concerned about backwards compatibility, a global switch/property could be added to change this default behavior.
Hello,
What do you think about changing the name of the entity? Do not get it from class but get from static method? I looked at the code, need to change some common methods.
The tests seem quite old, using code that has been removed from the project some time ago. I get 7 failures when trying to run the tests.
Hi,
Nice little library, but found an issue with -saveNestedAsynchronousWithCallback:
; it seems to make sense that the callback should only be executed when the final parent context is reached, but in the current implementation the callback is executed after each asynchronous save. This means the block will be executed twice for a simple background context, for example.
I'm fairly sure this isn't intended. Anyway, keep up the good work!
if([localContext hasChanges])
{
//save and merge changes in main thread.
[localContext mergeWithContextOnThread:[NSThread mainThread] completion:^(NSNotification *note) {
}];
} else {
}
Hi there,
I'm wondering how do I set a merge policy. I tried this line of code but it's not working:
[[NSManagedObjectContext mainContext] setMergePolicy:NSOverwriteMergePolicy];
Thanks for help.
Best,
daniel
It would be really nice if NLCoreData would preform custom progressive migration.
Is it on your roadmap?
Just read a very interesting article about importing large sets of data into Core Data. Turns out that the nested background context solution that NLCoreData is also advocating is pretty shitty. The old style non-nested contexts and mergeChangesFromContextDidSaveNotification:
seems to be performing a LOT better.
Setting up this kind of Core Data stack is boring so it would be perfect if NLCoreData would handle this. I'm curious to hear your thoughts on this.
When running unit tests I'd like to use a persistent store of type NSInMemoryStoreType. However, it's hardcoded to NSSQLiteStoreType. Please provide a way to override (a la persistentStoreOptions).
Right now the NSPersistentStoreCoordinator is created with these options:
@{NSMigratePersistentStoresAutomaticallyOption: @YES};
For model migration to work, the options should be this instead:
@{
NSMigratePersistentStoresAutomaticallyOption: @YES,
NSInferMappingModelAutomaticallyOption: @YES
};
Can't NLCoreData make this easier? Now I have to supply my own storeCoordinator. A simple boolean would be much handier. Or a getter for the options, which is much easier to supply as well.
When updated to 0.4.5 (via CocoaPods) I get a lot of crashes related to saving a backgroundContext. 0.4.4 and before all worked fine.
I have a fetched results controller with the delegate correctly set. When I insert a new managed object, the controllerDidChangeContent:
method is called as expected. However, when I delete objects, this method is not called on iOS 5. It does work fine on iOS 6.
I am using this utility method for inserting and deleting objects:
+ (void)performChanges:(void(^)(NSManagedObjectContext *context))changesBlock withCompletion:(void(^)(BOOL success))completionBlock {
NSManagedObjectContext *context = [NSManagedObjectContext backgroundContext];
[context performBlock:^{
changesBlock(context);
BOOL success = [context saveNested];
if (completionBlock) {
dispatch_async(dispatch_get_main_queue(), ^{
completionBlock(success);
});
}
}];
}
The success BOOL is always YES, the changes are saved to the database (looking at it with a SQLite browser). Everything works fine, it's just that controllerDidChangeContent:
isn't called.
Excellent project sir. We have had serious problems with child contexts in our apps, pretty much the same as explained here
http://wbyoung.tumblr.com/post/27851725562/core-data-growing-pains
NLCoreData obviously provides a bypass via storeContext which solves the problem for us but I was more wondering what your thoughts on this are? Do you use child contexts yourself?
Using the following works:
s.prefix_header_contents = "#ifdef __OBJC__\n#import \"NLCoreData.h\"\n#endif"
Instead of:
s.prefix_header_contents = '#import "NLCoreData.h"'
Which is currently found in the cocoapods podspec.
Please update the podspec, thanks!
A declarative, efficient, and flexible JavaScript library for building user interfaces.
๐ Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. ๐๐๐
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google โค๏ธ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.