How to configure NSPredicate to search for objects with nil attribute

Question

I have a ManagedObject class , and one of the members of the class is NSDate . I would like to display all the objects of the class for which the date is NOT set. I tried using a predicate like this:

 NSPredicate *predicate = [NSPredicate predicateWithFormat: @"(date = NIL)"]; 

But I still get the objects where date set. What is the correct way to create a predicate for this?

Answer 1

I think this is a case sensitivity case. You can use "nil" or "NULL", but not "NIL". This works fine for me:

 NSPredicate *eventWithNoEndDate = [NSPredicate predicateWithFormat:@"endDate = nil"]; 

Answer 2

Figured it out. It was not possible to do this using a predicate with a string format, so I tried a predicate with a template, and it worked. Here is the code that gave me the objects whose endDate is set to NULL:

 NSPredicate *predicate = [NSPredicate predicateWithFormat:@"endDate = $DATE"]; predicate = [predicate predicateWithSubstitutionVariables: [NSDictionary dictionaryWithObject:[NSNull null] forKey: @"DATE"]]; 

Answer 3

https://developer.apple.com/library/mac/documentation/Cocoa/Conceptual/Predicates/Articles/pUsing.html#//apple_ref/doc/uid/TP40001794-SW4

the following code should work

 predicate = [NSPredicate predicateWithFormat:@"firstName = nil"]; 

Answer 4

There is a very unpleasant behavior for select queries, as described by Apple:

If the object in the context has been changed, the predicate is evaluated by its changed state, and not by the current state in persistent storage. Therefore, if the object in the context has been changed in such a way that it satisfies the criteria of the select queries, the query retrieves it even if the changes were not stored in the repository and the values ​​in the repository are such that they do not meet the criteria. Conversely, if the object in the context has been changed so that it does not match the query, the query will not retrieve it, even if the version in the repository does not match.

Perhaps you will clear the date elsewhere, and the fetch request includes results in which the date is nil in memory but still set to disk (in persistent storage), and therefore, when an object causes an error, it loads the object with the installed date.

My only advice would be to coordinate access to the context of the managed entity (for example, on NSOperationQueue ) so that any updates can be stored in persistent storage before executing the select query.