As always, congrats on the great library, you are doing a fantastic job.
I have an application that uses a UISearchBarDisplayController to show a filtered list. It is pretty much similar to the AdvancedTableSearch example project that Apple provides.
This issue might be related to #225 , but because that one talks about iOS5 and I'm using iOS6 (and later) and using bleeding edge XCode, I thought it might be good to bring it up just in case. While this may, or may not be a MagicalRecord specific bug, I'd thought I'd make you aware of the issue.
The version of MagicalRecord I'm using is from commit: cb59d04
- (BOOL)searchDisplayController:(UISearchDisplayController *)controller
Normally, in this method you need to take a searchString from the searchBar and create a NSPredicate to filter the CoreData objects and set the self.searchResults array with the results from the CoreData fetch.
I've noticed that the issue is with compound-like predicates.
Assuming the predicate below and assuming an entity name PocketVideo:
NSPredicate *testPredicate = [NSPredicate
predicateWithFormat:@"downloading == 0 AND (title CONTAINS[c] %@)",@"salsa"];
Update: The below produce the same result for downlaoding comparing against 'NO', 'YES', 1 and 0.
Given that self.searchResults is an NSMutableArray. The following are the results using different fetch methods:
//This returns the CORRECT results
self.searchResults = [[[PocketVideo findAll] filteredArrayUsingPredicate:testPredicate] mutableCopy];
//Using the normal Magical way of doing things
//Returns MISSING results
self.searchResults = [[PocketVideo findAllWithPredicate:testPredicate] mutableCopy];
//Using the Apple's example of how to fetch entities
//This also returns MISSING results (which indicates might be a CoreData issue)
NSFetchRequest *request = [[NSFetchRequest alloc] init];
NSError *error = nil;
NSEntityDescription *entity =
self.searchResults = [[NSManagedObjectContext.defaultContext
However, if we remove the downloading == 0 AND from the predicate and just leaving (title CONTAINS[c] "salsa"). All of them return the proper expected results.
downloading == 0 AND
(title CONTAINS[c] "salsa")
Again, I'm not a CoreData expert, but wanted to check with you guys first - to know if it's a known issue (and maybe get more information) before I file a bug with Apple.
What's the default value of downloading set to in your data model (I'm assuming it's a BOOL)? If it's set to None, that's not the same as NO.
Also, downloading == NO would read better than downloading == 0 here.
downloading == NO
downloading == 0
The default value was set to None and yes it was a Boolean value. I ran the example again by using your suggestion of 'NO' (and also used 'YES', 1 and 0). I had previously ran this with those variables, but since all provided the same results, I decided to leave it as downloading == 0 since it did not seem to matter and it was last thing I tested. Also, to be more specific, all entities when running the query above for diagnosing have the same downloading value (to remove that possible variability).
I also ran the example by setting the default value in the model to 'NO' (instead of None) and ran it again for 'NO', 'YES', 1 and 0. In all scenarios, Query1 produces the correct results; Query2 and Query3 both provide incorrect missing results (see my update in the original post to determine which 'Query' labels I refer to).
The code provided above was just for example and I actually do some variable binding and use a series of nested NSCompoundPredicates to actually build the final query (using the similar code provided in Apple's example). The single format string I provided above is presented there after I was able to diagnose the problem and get it down to the minimum viable set of commands that causes the issue and that way I don't clutter this post with a bunch of unnecessary code that I've tested to not be the part of the problem.
I think the issue might be less related to the predicate string, and to understanding why there are inconsistent results between query methods when using the same query predicate using the latest bleeding edge iOS version and bleeding edge Xcode version. Of course this could be a bleeding edge issue, which of course might be magically fixed in the future; but wanted to bring it up to your attention.
Given the age of this issue, and the volume of issues we have to work through, I've decided to close this alongside a number of other older issues.
If you can still replicate the issue under the latest in-development version of MagicalRecord (3.0 at the time of writing), please feel free to re-open and one of @magicalpanda/team-magicalrecord will take another look. Thanks!