In my NSFetchedResultsController, I set a sortDescriptor that sorts based on the date property of my managed objects. The problem that I have encountered (along with several others according to Google) is that nil values are sorted at the earliest end rather than the latest end of the date spectrum. I want my list to be sorted earliest, earlier, now, later, latest, nil. As I understand it, this sorting is done at the database level in SQLite and so I cannot construct my own compare: method to provide the sorting I want.
I don't want to manually sort in memory, because I would have to give up all of the benefits of NSFetchedResultsController. I can't do compound sorting because the sectionNameKeyPaths are tightly coupled to the date ranges. I could write a routine that redirects indexPath requests so that section 0 in the results controller gets mapped to the last section of the tableView, but I fear that would add a lot of overhead, severely increase the complexity of my code, and be very, very error-prone.
The latest idea that I am considering is to map all nil dates to the furthest future date that NSDate supports. My left brain hates this idea, as it feels more like a hack. It will also take a bit of work to implement, since checking for nil factors heavily into how I process dates in my app. I don't want to go this route without first checking for better options. Can anyone think of a better way to get around this problem?
Update
A possible better way to get around this problem would be to switch to a binary persistent store. From what I have read in the documentation, sorting is done in Objective-C with the binary persistent store, so I could supply my own compare method for the date sorting. I have two concerns with this approach. First, what kind of performance hit am I going to see by moving to a binary store? Second, how difficult is it going to be to roll out this change in an app update?