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: Ben Trumbull <email@hidden>
- Date: Tue, 25 Aug 2009 16:21:15 -0700
On Aug 25, 2009, at 7:19 AM, Ruotger Skupin wrote:
Am 24.08.2009 um 23:13 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.
(this is 10A432)
For the record: I do use one-way relationships
That should be okay as long as you're not pretending to use a no
inverse to-many relationship as a de facto many to many
relationship. No inverse relationships can only behave as if the
inverse were to-one. Specifically, each row in the destination
entity may only be associated with a single row in the source
entity if the relationship on the source entity does not have an
inverse. (e.g. you only get join tables in fully modeled bi-
directional relationships)
Do I understand that correctly? No two (or more) Accounts or
Transactions should "point" to the same Amount (see simplified
schema). Unless there's a bug somewhere that's not the case.
Correct. For each separate modeled no inverse relationship, the
destination row (Amount) can only be pointed to by one source row.
|-------------|
| 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.
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.
- Ben
_______________________________________________
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