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
#0 0x97503f26 in objc_exception_throw ()
#1 0x944279db in -[NSObject(NSObject) doesNotRecognizeSelector:] ()
#2 0x94383026 in ___forwarding___ ()
#3 0x94382bf2 in __forwarding_prep_0___ ()
#4 0x97b3acae in -[NSSQLCore
_prefetchRelationshipKey:sourceEntityDescription:sourceObjectIDs:prefetchRelationshipKeys:inContext
:] ()
#5 0x97b3ab87 in -[NSSQLCore
_prefetchWithFetchRequest:withObjectIDs:inContext:] ()
#6 0x97b3d159 in -[NSSQLCore
_prefetchRelationshipKey:sourceEntityDescription:sourceObjectIDs:prefetchRelationshipKeys:inContext
:] ()
#7 0x97b3ab87 in -[NSSQLCore
_prefetchWithFetchRequest:withObjectIDs:inContext:] ()
#8 0x97b2c106 in newFetchedRowsForFetchPlan_MT ()
#9 0x97b164e7 in -[NSSQLCore newRowsForFetchPlan:] ()
#10 0x97b15d75 in -[NSSQLCore objectsForFetchRequest:inContext:] ()
#11 0x97b15991 in -[NSSQLCore executeRequest:withContext:] ()
#12 0x97b14ae1 in -[NSPersistentStoreCoordinator(_NSInternalMethods)
executeRequest:withContext:] ()
#13 0x97b11fff in -[NSManagedObjectContext executeFetchRequest:error:]
()
#14 0x00010b6e in +[GPPayPalTransaction
transactionsWithPredicate:sortDescriptors:returnObjectsAsFaults:relationshipKeyPathsForPrefetching:inManagedObjectContext:error
:] (self=0x10ebd4, _cmd=0x6a180, inPredicate=0x0,
inSortDescriptors=0x10adb80, inAsFaults=0 '\000',
inPrefetchKeyPaths=0x10ff990, inContext=0x10ad7e0,
outError=0xbfffe73c) at /Users/roddi/Development/GaragePay/
GPPayPalTransaction.m:100
(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.
|-------------|
| 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.
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)
AdditionalInfo has a one-to-one two-way relationship with Transaction
(not depicted above).
Hope that helps
Ruotger
_______________________________________________
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
