I'm implementing core data in my iphone app. It has two entities.
Entity1: LatestData
Entity2: LatestDetailedData
LatestData has URL, publishedDate, heading
LatestDetailedData has URL, NewsDescription, PublishedDate, Author
Both entities have same URL for a record.
Both the entities are connected with inverse relation ship. And the relation ship is "delete->Cascaded"
What I want: If I remove a record in LatestData, I want the record with same URL in LatestDetailedData must also be deleted.
How?
If I am understanding you correctly, you are using a relationship and it has an inverse. If that is the case then when you delete one then Core Data will automatically delete the other and you don't need to do anything extra.
What are you seeing that suggests that is not happening?
Update
Since you are using multiple threads, are you using one NSManagedObjectContext per thread? If so, are you updating all of the threads when a save occurs? I suspect one of those two is not occurring and therefore causing your issue.
when you create the entities you need to create the relationship too
LatestDetailedData * entity2 = [[NSEntityDescription insertNewObjectForEntityForName:#"LatestDetailedData" inManagedObjectContext:context];
entity1.lastestdetail=entity2;
if you are just relying on a URL field, then thats bad practice. Set up the relationship in coredata and the cascaded deletes will take care of themselves.
Related
I have a core data design with multiple tables using relationships. My database is SQLite. For updates I import data from JSON and use this method:
[NSEntityDescription insertNewObjectForEntityForName:entityName inManagedObjectContext:context].
I have added unique constraints in core data.
If I update an entity that is a relationship of another object it loses the connection.
Ex: Entity "person" that contains the one to one relationship to "pet_id". If I update "pet" it changes his id and "person" still points to the old id, so they are not related any more.
Is there a way to avoid this problem?
I don't think this is documented anywhere yet. Here's what it sounds like is happening:
You create a new instance. Your constraints mean that this instance matches an existing instance. But...
Your new instance has a nil value for this relationship. So...
The existing instance's value for the relationship is replaced by this new nil value.
To maintain the relationship, your new instance needs to already have the correct value for that relationship. You're essentially asking that the constraint matching system ignore the fact that the relationship value is different in your new instance, but to accept new values for other attributes.
I think what you're expecting is completely reasonable but I'm also not surprised that the current implementation doesn't support it. I recommend filing a bug with Apple about this, and investigating non-constraint based approaches to keeping your data unique.
I'm in the process of removing RestKit from our iOS app. I'm able to get things that I want into Core Data, but they're not really connected.
For example, we have one network call that returns a list of "Category"s (which have a "categoryID" and a "categoryName"; "Category"s also map to-many "StoreLocation"s). We then have another network call that returns a list of "StoreLocation"s (which, among other things, have a "storeName", "storeID", "storeCategoryIDs"; "StoreLocation"s also map to-many "Category"s).
With RestKit, I could use a RKConnectionDescription to describe that "storeCategoryIDs" drove the relationship to-many "Category"s. With that, if I had a given Category object, I could easily determine which StoreLocations belonged to that category.
I'm struggling to see how to accomplishing this without any RestKit dependencies. I suppose I could, whenever I'm about to insert a new Category or new StoreLocation, fetch all of the opposite managed objects and do this manually, but I seem to be missing some component of Core Data that can do.
The main part you're missing is the predicate applied to the fetch and which uses the identification attributes to find the appropriate existing objects. You do need to run your own fetch as core data will not magically update one object if you create a different new object and insert it.
I am using coredata to save the server data through web services in my application and I am storing relationships as an object to the entity.
I have many entities e.g "Inspirations" and "Products" and both are related to each other. I have a problem whenever the records are updated in the third entity which is "Filters" then the relations of the entities broke and I cannot apply filters on the entities.
[object addRelatedInspirationsObject:related];
This is how I save relationships. I am not able to figure out why the relations are being broken once the entity is updated which has no direct link with the entity.
One thing more if I fetch and save the data of any one of the entities like "Inspirations" then all the relations start to work again.
Your code should work. Here are 2 things you need to check:
Make sure related is not nil when you call your method.
Make sure you call save on a valid managed object context.
From your question it seems that entities have 1 to many relationship between them. And by the code you supplied, every things should work fine. Just make sure, you are using the Filter object from the relationship like object.filter (or obj1.obj2.filter), not accessing it via a direct NSPredicate on Filter entity and updating it. And if you are using FRC, you might also need to generate a fault against the parent entities, to get your UI updates.
I have 2 entities. ObjectA stores all ObjectB's objects through a many-to-many relationship. ObjectA also stores one specific object as a default object using a one-to-one relationship. The idea is to be able to assign many different child objects for EntityA while also keeping a specific reference to one specific child object. This idea works perfectly fine all throughout my project exempt in one circumstance(identical code and identical entity relationship setups.
The problem I am having is when I reassign the existing defaultObject to a new different object by simply ObjectA.defaultObject = someObject23; this assigns the new object correctly but in the process my original To-Many relationship reference to that existing defaultObject goes null.
The to-many relationship 'AllObjects' from EntityA has a Cascade delete rule for EntityB.
The One-To-One relationship 'DefaultObject' has a NULL delete rule for EntityB.
Both have inverses set.
Here is a real quick overview.
ObjectA.allObjects = 10 objects; // 1 of these is someObject1
ObjectA.defaultSomeObject = someObject1; // This works fine.
ObjectA.defaultSomeObject = someObject2; // This assigns the new defaultSomeObject=someObject2,
// but in the process it removes the someObject1 from my ObjectA.allObjects array (Goes NULL)
I'm stumped because like I say I have used this technique multiple times and the only workaround to this I have succeeded with is to "rig" it and actually save a reference to the previous object, delete it from the ObjectA array, set the new defaultObject, then write that object back to the array. There must be a simple explanation I am overlooking. More coffee? lol. Any help is greatly appreciated. I have tried all the different delete rules for each relationship as well just for kicks.
Problem solved. Definitely needed more coffee. What was happening was the one-to-one relationship was using the to-many relationship inverse causing it to do exactly what it was supposed to do, go null...
When I retrieve an entity from the one side of a one-to many relationship, I create a mutable array from the set that is the collection of entities from the relationship. I manipulate, edit or otherwise change those entities, possibly delete existing or add new.
When through with the changes I simply use the array to create a new set then replace the original set with that which I created like so:
self.myOneSideEntity.theManySideEntitiesRelationship = [NSSet setWithArray:myNewArrayOfEntities];
It occurred to me that replacing the set may not be deleting the old members. What happened to them? Is this the proper way to edit the collection of related objects? Am I leaving any kind of orphans or going against best practices with this technique?
My relationship is set up with an inverse, cascade delete on the one side, nullify on the many side and the inverse relationship is not optional.
I've spent some days to understand similar behavior in my application.
Relation's "Delete Rule" works only when the object that contains relation is deleted itself. If you simply replace one set of objects with another (as you do) - nothing happens. Child objects that were in old set will simply have inverse relations set to nil. So if that relation (from child side) is not optional, you will get CoreData error when saving context.
For now I didn't find any way to manage this, except manual deletion of old objects.
For me the issue was with getting objects which were wired with current object. (groupObject.docs)
It was solved when I add context by which I get this data.
I'm using MagicalRecord:
[GroupObject MR_findAllInContext:[NSManagedObjectContext MR_defaultContext]]
instead of
[GroupObject MR_findAll]