Re: Core Data Fetches + Transient Properties + NSPredicateEditor = Sadness
Re: Core Data Fetches + Transient Properties + NSPredicateEditor = Sadness
- Subject: Re: Core Data Fetches + Transient Properties + NSPredicateEditor = Sadness
- From: "Melissa J. Turner" <email@hidden>
- Date: Wed, 22 Apr 2009 14:34:32 -0700
On Apr 22, 2009, at 02:12, Mike Abdullah wrote:
On 22 Apr 2009, at 08:48, Ben Trumbull wrote:
Of course, why Apple couldn't have then added automatic support
for in-memory matching as the second step I don't know
Probably because nobody ever cared enough to file an enhancement
request, and it didn't occur to us that writing 1 line of code to
call filteredArrayWithPredicate was so troublesome.
Calling -filteredArrayWithPredicate is no hassle, but for a large
predicate, it has the bad performance of comparing a bunch of the
persistent properties all over again, despite already knowing
they'll match the predicate. Since I assume Core Data must do some
kind of internal splitting up of the predicate in order to perform
its fetch, I'd have thought it is in a good position to know what
the remaining transient portion of the predicate is.
You assume incorrectly.
CoreData simply translates the predicate to SQL and passes it down to
SQLite as a WHERE clause. Hence the lack of support for transient
properties: SQLite has no idea what to do when you ask it to qualify
by a column that doesn't exist in its schema.
+Melissa
_______________________________________________
Cocoa-dev mailing list (email@hidden)
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:
This email sent to email@hidden