Re: Core Data dog-slow when using first time after boot
Re: Core Data dog-slow when using first time after boot
- Subject: Re: Core Data dog-slow when using first time after boot
- From: Ruotger Skupin <email@hidden>
- Date: Thu, 3 Sep 2009 13:49:03 +0200
Am 26.08.2009 um 01:21 schrieb Ben Trumbull:
When I use setRelationshipKeyPathsForPrefetching the fetch throws:
-[NSSQLAttribute inverseRelationship]: unrecognized selector sent
to instance 0x10ee150
Can you provide the entire stack trace at this point ? gdb use
future-break objc_exception_throw
Thanks. What is the actual set of keypaths you set in the fetch
request ? setRelationshipKeyPathsForPrefetching expects all the
keypaths to terminate in a relationship object, not the attribute
off that related object.
Yes, that was the problem.
|-------------|
| Transaction |
|-------------| |--------|
|net | ------> | Amount | <<------ (one other entity)
|gross | ------> |--------|
|fee | ------> |value | <<-
|account | <<- |currency| |
|... | | |--------| |
|-------------| | |
| |
---------- |
| |
| |------------| |
| | Account | |
| |------------| |
| |balances | ----------
--> |transactions|
|... |
|------------|
So basically I use Amount only as a container for a currency
descriptor and a value. I would have to model 7 inverse
relationships on that entity to make all relationships two-way.
Hmm. I'd recommend consider whether or not it makes sense to de-
normalize Amount into Transaction instead of making it a separate
entity. I assume the net/gross/fee are all going to be in the same
currency, yes ? Amount is very fine grained, and not (apparently)
offering very much value for the abstraction cost.
Will do that. At least for the amounts in Transaction.
Since it's not a many to many, you can perform the prefetching
effectively by hand using a fetch request to preload the relevant
destination rows with an IN query based on the data you initially
fetched for the source entity. You shouldn't have to, but if
you've run into a bug, that's how you could workaround it.
You still haven't described the NSPredicate you were using with
filteredArrayUsingPredicate. Being more forthcoming about the
context and details of your problem will help us get you answers
more quickly.
This is the predicate I was using for the test of the original
post, but since I use Smart Folders predicates can look a lot
different (i.e.: complex):
(additionalInfo.onTheFlyIsInternal == 0 AND
additionalInfo.isSuppressed != 1) AND (account.uniqueID IN
{"D1AB3788-00DF-4475-A979-CE3EFC3987B5"} OR FALSEPREDICATE)
You'll want to prefetch additionalInfo and account.
Hm. Problem here is: As mentioned I use the predicate for a smart
group. So the predicate can vary wildly and can reference basically
any entity in the model. So what is the best strategy here?
"Decompile" the predicate (which is built by an NSPredicateEditor) and
prefetch the keypaths it takes? Prefetch "everything"?
Kind Regards
Ruotger
_______________________________________________
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