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
keyPathsForValuesAffectingValueForkey. Look at the little script I
have in my Xcode scripts
On 2009 Apr 23, at 13:53, Melissa J. Turner wrote:
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.
I don't know if a derived
On Tue, Apr 28, 2009 at 5:15 PM, Jerry Krinock je...@ieee.org wrote:
If Melissa is referring to a managed property, if it is non-transient, then
yes this could be used in the predicate of a Core Data fetch. The
disadvantage is that now every object in every store has this redundant
(derived)
(apologies for the delay; I've been on vacation for the last few days
and just got back)
On Apr 28, 2009, at 14:32, Kyle Sluder wrote:
So step 1 is to stop clinging to normalization rules. (My database
professor would kill me for that sentence, but it's true.) There
really is no redundancy
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
On 2009 Apr 23, at 13:53, Melissa J. Turner wrote:
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.
Melissa, please give a more
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
On 2009 Apr 23, at 05:18, Mike Abdullah wrote:
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
On 23 Apr 2009, at 15:03, Jerry Krinock wrote:
On 2009 Apr 23, at 05:18, Mike Abdullah wrote:
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:
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
The fact that Core Data cannot fetch using a predicate based on
transient properties [1] seems to greatly limit the utility of the
NSPredicateEditor view, and makes me very sad.
Dear list.
transient (adj):
(1) passing especially quickly into and out of existence
May I suggest that the
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
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,
Problem solved. Although predicates cannot involve transient
properties, you can follow relationships in a predicate using a key
path. Obj-C Categories to the rescue…
For example, you can write a category on NSNumber containing a method -
letterGrade. Then use this to create the
guess the reason why Apple has never noticed that Core Data
Fetches + Transient Properties + NSPredicateEditor = Sadness is
because there's a better way to do it.
Makes me wonder why NSFetchRequest even supports a predicate, since
its predicate has all these limitations and is supposedly more
On Mon, April 20, 2009 11:02 am, Jerry Krinock wrote:
Makes me wonder why NSFetchRequest even supports a predicate, since
its predicate has all these limitations and is supposedly more
expensive when compared to fetching all objects and then using -
[NSArray filteredArrayWithPredicate:] ? It
On Apr 20, 2009, at 2:02 PM, Jerry Krinock wrote:
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:
If you
On 4/20/09 11:02 AM, Jerry Krinock said:
But there's an even better way. Upon further study of the Predicate
Programming Guide, I find that there are even more limitations to Core
Data fetches with predicates. The most troubling is that:
The Core Data SQL store supports only one to-many
On 2009 Apr 20, at 11:24, Jim Correia wrote:
On Apr 20, 2009, at 2:02 PM, Jerry Krinock wrote:
Makes me wonder why NSFetchRequest even supports a predicate, since
its predicate has all these limitations and is supposedly more
expensive when compared to fetching all objects and then using
If it helps, the reason for Apple only supporting searching of
persistent properties is for performance. If you're using the SQLite
store for example, the predicate is not evaluated against the in-
memory objects, but against the individual bits of data in the SQLite
table. Of course, why
On Apr 16, 2009, at 9:01 PM, Jerry Krinock wrote:
The fact that Core Data cannot fetch using a predicate based on
transient properties [1] seems to greatly limit the utility of the
NSPredicateEditor view, and makes me very sad.
For example, say that my objects are student test results
The fact that Core Data cannot fetch using a predicate based on
transient properties [1] seems to greatly limit the utility of the
NSPredicateEditor view, and makes me very sad.
For example, say that my objects are student test results with a
'score' attribute and two dozen other
22 matches
Mail list logo
