On 2009 Apr 22, at 01:26, Ben Trumbull wrote:
"The Core Data SQL store supports only one to-many operation per
query; therefore in any predicate sent to the SQL store, there may be
only one operator (and one instance of that operator) from ALL, ANY,
and IN."
Do you have a specific scenario in which you need to perform nested
to-many operations, yet you cannot use SUBQUERY or compound queries
like OR ? Or is this troubling, in the sense that the universe is
doomed to evaporate kind of way ?
Well, I'd rather give my users NSPredicateEditor and let them make
that decision. I'm sure that the code which Apple has written to
generate predicates in NSPredicateEditor is better than any that I
could write, not to mention that Lazy Programmer thing. However, it
appears that NSPredicateEditor can produce compound predicates that
violate the rule given above. For example, here's one that I just
produced in my app:
isAllowedDupe == 1 OR dontVerify == 1 OR shortcut CONTAINS "stuff" OR
comments CONTAINS "" OR type == 3840 OR name CONTAINS "M" OR (url
CONTAINS "a" AND tagsString CONTAINS "apple")
A much better way appears to be to fetch all objects from the store
with no predicate and then use -[NSArray
filteredArrayWithPredicate:]. This takes only one more line of code,
solves all problems, and is supposedly cheaper too:
This does not solve all problems, it most emphatically is NOT
cheaper, and most assuredly does NOT scale....
Thank you, Ben. I understand about the scaling now.
But for applications with typically small data sets, I believe that -
filteredArrayWithPredicate can be a good, practical solution for
developers who'd like to "leverage the power of NSPredicateEditor" in
exchange for having a few users with not enough RAM to hold all their
objects experience some hard disk access.
Performance is always something that needs to be tested, anyhow. The
managed objects in my app have 35 properties and I rarely see a user
with more than 1500 objects. Searching is something that the average
user might do once a week. I have an early 2006 Mac Mini with 2 GB
RAM. Filtering an array on a test database of 5000 objects looks like
it takes maybe 20 milliseconds or so.
So, yes it would be nice to optimize the search, maybe doing a fetch
with Core Data and then further filtering the array as someone
suggested. I'll probably do some more testing, but at this point my
cost/benefit analysis says to wait until, if ever, it becomes an issue
for someone. Maybe Apple might provide an easier solution by then ;)
(Yes, I know about the ER procedure.)
_______________________________________________
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
