On Apr 23, 2009, at 05:18, Mike Abdullah wrote:
On 22 Apr 2009, at 22:34, Melissa J. Turner wrote:
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.
OK, so I'm trying to wrap my head around this. Let's say I build a
predicate along the lines of:
fooPersistent == 123 && fooTransient == 456
And then use it in a fetch request. Does Core Data:
A) Pass that predicate straight to SQLite which fails because it
can't find a fooTransient column.
B) Pass that predicate straight to SQLite which ignores fooTransient
(presumably treating it as always evaluating to true).
C) Create a "fooPersistent == 123" predicate and pass that to SQLite.
Or of course D) something I've failed to conceive of which seems
quite probable!
D) It varies by store. The SQL store does something close to A, other
stores do different things. Feel free to experiment and discover
them ;-)
Unwinding to the original message, the most correct thing to do would
be to add a derived property letterGrade which is automatically
updated whenever grade is, which then allows you to search against that.
The best uses for transient properties are infrequently used
properties and caches that are not directly displayed. If a value is
something you're expecting to use regularly (as in a search), it makes
more sense to persist it due to the overhead of recalculating.
Personal opinion: Data design is all about knowing when to normalize,
and when throw the textbook away and denormalize because it makes
sense. 3rd normal form is theoretically really spiffy, and kind of
sucks in the real world where joins are expensive operations and doing
extra I/O avoid 1 byte of storage per row is kind of silly.
+Melissa
_______________________________________________
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
