(Apologies if this message reaches you in duplicate. The first time I sent it, it was flagged as 10 KB too large.)
I spoke too soon... Forcing -indexOrName to be invoked at entity creation time ensures that the corresponding attribute has the correct value but the fetched results controller sorts the list as follows: First descending by "selected" (as desired) Then, within the selected group, ascending by "index" (as desired) But, within the deselected group, it sorts them incorrectly by "name". (see picture) Note how Egypt appears before Denmark and Morocco before Honduras. The numbers within parentheses are the entities' "index" values. I've verified that -indexOrName returns the correct value for each entity (which means the values stored in the store for that attribute should be correct), and replacing "indexOrName" with "name" in the second sort descriptor defined for the fetched results controller sorts the names correctly. So, why doesn't it sort them correctly when it's accessing the "indexOrName" stored value? At first I thought that this might be due to using Cocoa sort descriptors with an SQLite store, as explained in http://developer.apple.com/library/ios/documentation/cocoa/conceptual/CoreData/Articles/cdTroubleshooting.html#//apple_ref/doc/uid/TP40002320-SW16 === SQLite store does not work with sorting Problem: You create a sort descriptor that uses a comparison method defined by NSString, such as the following: NSSortDescriptor *mySortDescriptor = [[NSSortDescriptor alloc] initWithKey:@"lastName" ascending:YES selector:@selector(localizedCaseInsensitiveCompare:)]; You then either use this descriptor with a fetch request or as one of an array controller's sort descriptors. At runtime, you might see an error message that looks similar to the following: NSRunLoop ignoring exception 'unsupported NSSortDescriptor selector: localizedCaseInsensitiveCompare:' that raised during posting of delayed perform with target 3e2e42 and selector 'invokeWithTarget:' === However, I'm not using a "custom" comparison method and I don't get any runtime error messages. In fact, I'm using the same sort descriptor as in the example found in http://developer.apple.com/library/mac/documentation/Cocoa/Conceptual/CoreData/Articles/cdFetching.html#//apple_ref/doc/uid/TP40002484-SW3 namely NSSortDescriptor *sortDescriptor = [[NSSortDescriptor alloc] initWithKey:@"firstName" ascending:YES]; except that "firstName" is replaced by a derived property (defined as a transformable attribute), "indexOrName", which does produce a string for the entities in the deselected group. Incidentally, the documentation is VERY confusing in this regard since in the blob above it suggests that -localizedCaseInsensitiveCompare: is not supported and could/would cause an exception to be raised while in http://developer.apple.com/library/mac/documentation/Cocoa/Conceptual/CoreData/Articles/cdPersistentStores.html#//apple_ref/doc/uid/TP40002875-SW11 it says "The supported sort selectors are compare: and caseInsensitiveCompare:, localizedCompare:,localizedCaseInsensitiveCompare:, and localizedStandardCompare: (the latter is Finder-like sorting, and what most people should use most of the time)." I am extremely frustrated by all this. I've already spent the better part of a week trying to figure this one problem, creating an NSFetchedResultsController that sorts using multiple keys, at least one of which is defined by a derived property, which I would think is a common task, and I'm not making much progress. I most definitely could use someone's help here. I've done all the doc-reading, I've done all the code-walking and debugging, and I've narrowed the problem down to a very specific issue, but I'm still not seeing the light. The most recent test project can be found here: http://www.restlessbrain.com/FRC_Test_2.zip I'd be grateful if someone could look at that project and help me figure out what I'm doing wrong. Thanks in advance. WT
<<inline: picture.png>>
> Your statement that I need to get the values of "indexOrName" stored in the > store led me to write the odd-looking line of code below > > cdCountry.indexOrName = cdCountry.indexOrName; > > when the entities are created and it fixes the problem in the test project. > I'm now more convinced than ever that CD stored an empty NSData object for > each "indexOrName" entry, which would explain why their values weren't nil > and, yet, they sorted "randomly." > > Now on to the actual project. Hopefully this is all that is needed. > > Thanks again for your message. > WT
_______________________________________________ Cocoa-dev mailing list ([email protected]) Please do not post admin requests or moderator comments to the list. Contact the moderators at cocoa-dev-admins(at)lists.apple.com Help/Unsubscribe/Update your Subscription: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to [email protected]
