On Feb 10, 2011, at 3:54 PM, Quincey Morris wrote:
> Perhaps you're assuming that Core Data will internally call the above getter
> to figure out what to put into the store. It doesn't work that way. Most
> likely your store contains nil values for the "indexOrName" attribute. (I'm
> assuming your Core Data model actually has an "indexOrName" attribute. If
> not, it still won't work, but for a different reason.)
Yes, that's what I assumed. Yes, the Core Data model does have an "indexOrName"
attribute (defined as transformable). No, the values for "indexOrName" stored
in the store aren't nil. In fact, here's actual output from the test project:
2011-02-10 16:03:17.083 FRC_Test[13683:207] <CountryCD: 0x61315b0> (entity:
CountryCD; id: 0x6105ee0
<x-coredata:///CountryCD/t127003C3-3CE9-4CFB-A060-22A88CA1BB702> ; data: {
index = 0;
indexOrName = "(...not nil..)";
name = India;
selected = 1;
})
This output happens long before the fetched results controller is created, by
the way.
I assumed that CD internally calls the getter because it actually has happened,
although it isn't entirely clear to me under what circumstances. It appears
that once an entity has some attribute changed that affects the fetched results
controller, then the next fetch operation does sort the entities as I intended,
ie, by invoking the getter for "indexOrName". I thought that this might be due
to the fact that the first fetch happens before I assign the FRC's delegate but
that isn't the case (I tested this by doing the obvious: fetching after setting
the delegate).
Also, how is it that "indexOrName" has non-nil values without the getter being
called? I suspect that CD stores some empty NSData object for each
"indexOrName" entry (since it's defined as an optional transformable attribute)
but doesn't call the getter.
> The thing you're sorting is a fetched results controller. Presumably that
> sorts itself based on the fetched attribute values (all nil for "indexOrName"
> in this case), which means that all objects have the same value for the
> attribute, so the result of sorting is essentially random, as you've seen.
That would make perfect sense if it wasn't for the fact that the stored values
for "indexOrName" aren't nil.
> You either need to get the actual values of "indexOrName" into the store, or
> you need to do your own sorting after the objects have been fetched.
I think the former is already the case, hence my surprise that the sorting
isn't happening as expected.
At this point, I don't know how to debug this any further since the internal
workings of NSFetchedResultsController aren't accessible to us (to me, at
least).
In the absence of figuring out why this isn't working, let me put it
differently: how can I create an NSFetchedResultsController that sorts based on
multiple keys, at least one of which is a derived attribute? I'll be surprised
if this isn't a common task.
Thanks for your help.
WT_______________________________________________
Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
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 arch...@mail-archive.com
