Thanks to Kyle and Melissa for the further explanation.
So, I thought about it some more and agree with you that putting a few
redundant bits on the disk is not sinful, and actually I am a fan of
keyPathsForValuesAffectingValueFor<key>. Look at the little script I
have in my Xcode scripts menu! [1]
But the other issue -- the inability of a Core Data fetch to handle
arbitrary predicates produced by NSPredicateEditor -- weighs heavily
against Core Data fetches. I made my own simple predicate editor
control a few years ago, but of course it is a pile of garbage
compared to NSPredicateEditor, and I just can't go back to 2006 now.
So I still plan to use NSPredicateEditor, fetch all and filter with -
[NSArray filteredArrayWithPredicate:].
I have used sqlite3 directly myself and don't recall any limitation on
the number of ALL, ANY or IN clauses. If there is not, then maybe
Apple would be responsive to a enhancement/bug report on Core Data
fetches not being able to handle predicates from NSPredicateEditor.
And if I'm lucky Apple will fix it before any of my users has a data
set large enough to require hard disk access during a search :)
Jerry
[1] Script for coding +keyPathsForValuesAffecting...
#!/bin/sh
echo "+ (NSSet*)keyPathsForValuesAffecting {"
echo " return [NSSet setWithObjects:"
echo " @\"\","
echo " nil] ;"
echo "}"
echo
_______________________________________________
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
