Is it possible to set different maximum number of objects in a two many relationship in core data? I was thinking it might be possible with the NSRelationshipDescription -setMaxCount: method, but I can't figure out where to call this. Would I call it in a custom +initialization method?
You can use a setting to set the maximum number of objects. Use the core data inspector to set your property on your relationship.
Related
I have a number of entities that describe different pieces of equipment.
I read these into the EquipmentViewController.
I'm struggling to figure how to use a generic EquipmentDetailViewController that can be used to show and update any of the different entities.
I have it working by having a separate DetailController to manage the details of each entity, but there has to be a better method.
I could possibly merge the entities, but I think that would be unwieldy.
If I could name a variable to hold any entity, I would be set. Is that possible (or correct)?
This must have come up before but I could not find an answer that I understood. If there is one, please point me to it, and I'll close this question.
TIA
In my app I have two instances of two different classes fetching the same core data object and grabbing a pointer to it in their respective properties. Then my two instances they both modify a different attribute in the core data object and save context at different moments. Is this going to create inconsistencies or merge conflicts in my app or will core data manage well this process? I've read about uniquing in the Core Data Programming Guide but I'm not sure I can extrapolate to my case the example they use.
Thank you.
This isn't a merge, it's just an update. There is only one instance of the managed object and multiple different pointers to it. If you check the address of the managed object instance you can verify this. So no, there are no issues (so long as you do all this on the same thread that owns the instance of course).
The uniquing you refer to relates to inserting multiple instances which both have the same unique identifier and is a different situation than you describe.
I'm running into an issue with my core data model. I would like to have an entity called TherapySession have two Mood events - start and end. To do so I've defined two relationships to child objects:
However, I would also like to create an inverse relationship, where each Mood object would be aware of it's parent therapy session. I'm not sure how to properly create the inverse relationship between the child and parent object when there are more than one relationship of the same type defined. In my case, the inverse relationship points to the "startMood" property of the therapy session:
It seems that I'm doing something wrong, but I cannot put my finger on how to resolve this problem. If I add an end mood to therapy, and the core data would try to create an inverse relationship, would it overwrite the startMood relationship?
Thank you for any clarifications! I know that this can be avoided by adding a set of objects, and then sorting the set by date, but I would like to avoid having to do that for every object.
One solution is to stick with a simple many-to-one relationship mood and an additional attribute in entity Mood that indicates start or end.
This is also more flexible - in the future it would be trivial to introduce more moods at different therapy points etc. without having to change the data model.
I'm not sure if this is the right way to do this, but I always end up creating two inverse relationships, like startMoodInverse and endMoodInverse. (You can then add a property in code that returns whichever of those is non-nil as therapySession.)
I want to delete the many-to-many relationship between two dynamic entities.
I've seen examples using dummy objects, but they were not dynamic. I will not know the object or the name of the objects' collection navigation properties until run-time. So I can't just say,
apple.Oranges.Remove(orange)
I need to do it dynamically. Something like,
dynamicModel.dynamicCollection(collectionName).Remove(otherDynamicModel)
I don't need extension methods necessarily, just something that gets the job done. How can I do this? Thanks.
(I don't know what other details might be helpful to provide since the objects are dynamic?)
I think you're best off using reflection in this case still:
((dynamic)dynamicModel.GetType().GetProperty(collectionName)
.GetValue(dynamicModel, null))
.Remove(otherDynamicModel)
Or if you know it will be an IList
((IList)dynamicModel.GetType().GetProperty(collectionName)
.GetValue(dynamicModel, null))
.Remove(otherDynamicModel)
Basically I have three different Core Data entities (A, B, C) and A contains a set of Bs and B contains a set of Cs. These three entities are, however, quite different from each other and they don't have common methods to access each other's children or the values to be displayed in the view.
I'm trying to display these three enties in an NSOutlineView. There's propably other solutions too but I came up with two different ones:
Implementing NSOutlineViewDataSource protocol and handling each of the entities differently.
Consolidate the classes with categories and add common (transient) methods/properties for the NSOutlineView to use. These methods/properties get their actual values from the model entities' properties.
I chose the second option and added getters for the children and the display value. This way, however, the Key-Value Observing does not work anymore and changes in the model are not reflected to the view. I understand why, but I'm not sure how to solve this the right way. I was thinking of some way to be notified of the actual model value changes and forward them to the view.
Is there any easy way to forward those notifications or should I consider some other alternative?
In short, I need to display different kinds of entities in an NSOutlineView and I don't want to mess the model.
Can't you just use relationship A->B->C to fetch the object A and display them in outline view?
After some trial and error, I found out that creating a custom data source is really that simple and decided to go with the first choice. Also, with drag & drop support this feels much more natural way.
The only issue was with outlineView:setObjectValue:forTableColumn:byItem: for which one needs to specify column identifier references. I feel that undirect dependencies are always something one should avoid, but this is a small matter in comparison to making this work nicely.