I have 2 Entities, related by a many-to-many relationship.
Thing<<->>Tag
There is one NSArrayController controlling the entity "Tag", bound to the managedObjectContext. By the array controllers add: and remove: action i can add instances of tag to the collection.
There is a second NSArrayController controlling "Thing" entities, also bound to the managedObjectContext.
So each of the controllers manages all instances of their entity.
Now, let's say there are 5 "tag" and 3 "thing" instances already created by their array controllers.
I'd like to link individual tags to a thing. I just want to create the relationship between an existing thing to an existing tag instance.
Is addObject: of NSArrayController the right method for that? Or does it create a new managedObject?
Would it be equivalent to:
NSMutableSet *tags = [aThing mutableSetValueForKey:#"tags"];
[tags addObject:existingTag];
?
Is there some best practice for a tagging system?
I've found it helpful (in the latest version of Xcode) to select the entity in the core data modeller, and then go to the file menu, and select new file -> Core Data -> NSManagedObject subclass. It automatically creates a class with the necessary members AND ALSO methods for adding objects in the toMany relationships.
If you've done that, then you just need to get ahold of the thing instance to which you want to add a tag and you can call the method declared for you to do so. How that method is named is obvious from the header file generated.
Related
How does one bind an NSArrayController's content to the entities in an ordered to-many relationship?
I have an unordered to-many relationship in my Core Data model, and an NSArrayController whose Content Set is bound to that relationship from the parent entity. This works fine, the data is accessible from the NSArrayController, no problem.
I decided during development that it would be better to allow users to manually reorder these child objects, so I changed the relationship to an ordered one. Now, when my NSArrayController is being created from my nib, the following error is presented:
Cannot create NSSet from object Relationship '...' fault on managed object ... of class _NSFaultingMutableOrderedSet
Now actually, I think this all makes sense: It's an ordered relationship, so now I'm getting an ordered set. Binding it to Content Array also would be inappropriate, since it's now an NSOrderedSet, not an array. My question is: Now how do I bind this relationship's data back into the NSArrayController?
I came across this discussion while searching to see if there've been any new developments on this front. In a shipping app I currently bind the array controller's content array to orderedSetKey.#array and it works just fine, not sure if I discovered that myself or if someone else suggested it somewhere.
The fundamental problem is that a Core Data ordered to-many relationship returns an NSOrderedSet, and NSOrderedSet is not a subclass of NSSet. Any array controller bindings that expect an NSSet will fail.
Tom Fewster has a detailed blog post describing the use of NSValueTransformer to work around this shortcoming, converting between NSOrderedSet and NSArray on the fly. He also provides a sample implementation on Github.
I'm currently wrapping my head around some problem with Core Data.
I have one user model in its own store that I do not have any control over, as it gets shipped with a framework. A Persistent Store Coordinator, Managed Object Model and Context for this model gets created automatically and cannot be touched. In it, this model has a single user entity
On the other hand, I have a properties model with a properties entity in it that I have complete control over. In there I store properties for some user entities in the other store. Both user and property entities have an id attribute similar to a foreign key.
This model has it's own Persistent Store Cordinator, Managed Object Model and Context.
What I now want is to have the associated user entity as an attribute of the properties entity so I might be able to bind to key-paths similar to myproperty.user.someValueOfTheUserEntity (I'm aware that myproperty might be an array when using fetched properties).
However, as cross-store relationships are not supported I thought of using a weak relationship via Fetched Properties. That one would just have to match the two corresponding id attributes. I have created a Fetched Property for the user in Xcode and the required accessors in my properties entity's class file (As suggested in other questions, I'm treating the values returned by the Fetched Property as an array).
However, I'm unable to set a destination entity for the Fetched Property in Xcode, as the target entity resides in a completely different store. Would I also have to define my user entity in the properties store? If so, how does Core Data know that that entity shall be fetched not from my properties store but from the users store?
Some threads mentioned using configurations for this, but I cannot find any documentation that goes further than mentioning "use configurations for this".
Can somebody enlighten me on how to set up cross-storage fetched properties? #
You can use several persistent stores that share the same data model:
Use single data model (xcdatamodeld) and add all your entities
Create configurations (Editor/Add Configuration) for each "logical set" of
entities that should be stored in separate store file
Assign (Drag) entities to appropriate configurations
Add configured persistent stores to your context (see below)
Configure fetched properties
// 1. Add "static", read-only store
[coordinator addPersistentStoreWithType:NSSQLiteStoreType
configuration:#"your static configuration name goes here..."
URL:storeUrl
options:#{
NSReadOnlyPersistentStoreOption: #(YES),
NSInferMappingModelAutomaticallyOption : #(YES)
}
error:&error];
// 2. Add "dynamic", writable content
[coordinator addPersistentStoreWithType:NSSQLiteStoreType
configuration:#"your dynamic configuration name goes here..."
URL:storeUrl
options:#{
NSMigratePersistentStoresAutomaticallyOption: #(YES),
NSInferMappingModelAutomaticallyOption : #(YES)
}
error:&error];
I have three views that I've manually created in the DB.
First view is "Region", the second is "FIPS" and the last is a many-to-many between them called "Region2FIPS". These are all views, and I only need read access the data, so I'm not worried about having updateable views.
I have added each of these views to Entity Framework, and created the appropriate associations between them.
Region to Region2FIPS is a 1 to many.
FIPS to Region2FIPS is a 1 to many.
The "Region2FIPS" view contains only two columns, one called "FIPSID" the other "RegionID". These column are associated with their respective views in the relationships I defined above.
When this type of association is made on tables in the DB, Entity Framework knows that it is a many-to-many relationship and it creates a navigation property on "Region" called "FIPS" that I can use to navigate through the child collection of FIPS. It does likewise for "FIPS" to "Region".
However, when done manually, with views, it does not exhibit that behavior. Instead, my "Region" object has a collection of "Region2FIPS" objects, which each have a navigation property called "FIPS" which is of type "FIPS". And my "FIPS" object has a collection of "Region2FIPS" objects, which each have a navigation property called "Regions" of type "Region".
I assume this has something to do with the fact that I can't create foreign key references on the views, so entity framework doesn't realize the many-to-many relationship. But I thought that if I manually created the many-to-many relationship between the views it would recognize it and properly handle the navigation between the types. Is there a way for me to force it to do this?
It's possible, but the designer doesn't really help you here. You have to do the mapping manually.
One fairly easy way is to use Code First mapping. But this means your model has to be Code First to begin with. If you're writing a new model, just do that.
If you're using DB First mapping, however, you will have to do the mapping manually. Your SSDL will probably already be correct, once you define the "primary keys" of the views. You would then have to remove the "Region2FIPS" objects from the CSDL (not just from the designer!) and manually patch up the MSL.
Perhaps the easiest way to do this would be to use the designer to automatically map real DB tables (not views) with a similar schema and then replace the table names with view names in the EDMX, using the XML editor.
I have a core data entity which has an exclusive one to many relationship with another entity. This relationship is supposed to be a basic containment the first entity contains one or more of the second. An instance of the second entity can only be contained in one of the first entities.
I want to be able to remove all the contained entities from the first entity and then delete them. How should I do this? Should I remove the relationship and then call deleteObject for each entity or will calling deleteIObject for each contained entity cause the relationship to be set correctly. If the second is true, can I just enumerate the contained entities and call deleteObject or should I first make a copy of the set (if calling deleteObject for each objects severs the relationship this will modify the set which is not allowed in normal enumeration).
Delete each child object via the NSManagedObjectContext and the relationship will clean up appropriately. This is assuming that you are following the convention and have all of your relationships configured to be bi-directional.
What's the best way to model ordered lists of items with core data?
As of OS X 10.6, there is no automatic way to maintain an ordered to-many relation in Core Data. You will have to add an "index" attribute to the target of the to-many relation and maintain this index manually or maintain a mapping from object ID to index in the entity that has the ordered to-many relationship. It's actually not that hard to implement the first of these options by overriding the KVC orderd to-many accessor and setter methods. You can also create a fetched property on the parent entity to make (read-only) access to the ordered list easier by adding a sort descriptor to the fetched property's fetch predicate.
If you are targeting Lion or newer you can create ordered to-many relationships directly in the data modeler. Those use the NSOrderedSet class.