iOS Does core data use inverse relationships for widows?

[1458279]

I noticed in a tutorial that Apple recommends having an inverse relationship in Core Data. I was wondering why.

Is it for Widows and Orphans? Is there some auto prune from the master file that Core Data does automatically and is there a setting that turns it off? Either way, couldn't that be dangerous?
What happens if you don't have an inverse relationship setup?

 

[Stella]

Yes, you are correct, core-data uses this to maintain data integrity between child / master relationships.
The parent should never be missing in a master / child relationship, in most cases.

This type of question has been asked frequently on Stackoverflow.com

 

[1458279]

Yes, you are correct, core-data uses this to maintain data integrity between child / master relationships.
The parent should never be missing in a master / child relationship, in most cases.

This type of question has been asked frequently on Stackoverflow.com

I saw a few on SO, but it didn't answer my question, so I thought I'd try here.
The concern would be about a lookup table that has a relationship but not always a match.
Example: zipcode can have all the zipcodes in it but not have a match in an address table. So if you setup a relationship where address table has 200 zipcodes used in it, but the zipcode has much more, would those that aren't used in one be deleted because they would be seen as orphans.

You'd want all the zipcodes even if they are never used.

Is there a setting for this so that they wouldn't be deleted?

 

[Stella]

This would be an issue of disabling cascade delete?

I've done this before in core data - a while back. I was on the info panel of the relationship IRC.

 

[1458279]

This would be an issue of disabling cascade delete?

I've done this before in core data - a while back. I was on the info panel of the relationship IRC.

Ok, thanks, I'll look up cascade delete. The example I'm doing now doesn't use that so it made me wonder how it was done.

 

[grandM]

I saw a few on SO, but it didn't answer my question, so I thought I'd try here.
The concern would be about a lookup table that has a relationship but not always a match.
Example: zipcode can have all the zipcodes in it but not have a match in an address table. So if you setup a relationship where address table has 200 zipcodes used in it, but the zipcode has much more, would those that aren't used in one be deleted because they would be seen as orphans.

You'd want all the zipcodes even if they are never used.

Is there a setting for this so that they wouldn't be deleted?

I think you are referring to the nullify option. Cascade does the following: grandfather: A, father: B, child C. If you delete A B and C will be deleted when cascade is selected. If however the relationship is set as nullify deleting A will not influence B nor C. So your Zip Code table can have zip codes which are no longer present in your Address table.
[doublepost=1456443887][/doublepost]Another remark: Core Data gives a warning if you do not set an inverse relationship. Let's call the relationship from A to B X. The inverse relationship from B to A would be Y. You can set the cascade versus nullify option on X and Y. They can differ. So you could impose a cascade for X and a nullify for Y. In your case a zip code can belong to several addresses. An address can only have one zip code. Upon deleting an address you need a nullify from Address to Zip Code. Because the deletion of an address may not delete the zip code for all addresses. So you need nullify. The inverse relationship? If a zip code would disappear this would effect all Addresses. However I think you still should use nullify. I reckon if you would choose cascade for the relationship between Zipcode and Address all addresses with that zipcode would be deleted upon deleting a particular zip code. You do not want that. So you also need nullify. This last one needs to be confirmed though.

 

[1458279]

I think you are referring to the nullify option. Cascade does the following: grandfather: A, father: B, child C. If you delete A B and C will be deleted when cascade is selected. If however the relationship is set as nullify deleting A will not influence B nor C. So your Zip Code table can have zip codes which are no longer present in your Address table.
[doublepost=1456443887][/doublepost]Another remark: Core Data gives a warning if you do not set an inverse relationship. Let's call the relationship from A to B X. The inverse relationship from B to A would be Y. You can set the cascade versus nullify option on X and Y. They can differ. So you could impose a cascade for X and a nullify for Y. In your case a zip code can belong to several addresses. An address can only have one zip code. Upon deleting an address you need a nullify from Address to Zip Code. Because the deletion of an address may not delete the zip code for all addresses. So you need nullify. The inverse relationship? If a zip code would disappear this would effect all Addresses. However I think you still should use nullify. I reckon if you would choose cascade for the relationship between Zipcode and Address all addresses with that zipcode would be deleted upon deleting a particular zip code. You do not want that. So you also need nullify. This last one needs to be confirmed though.

Ok, thanks. Clearly gets a bit complex. Looks like I'm going to have to set things up and run some tests.
I wonder what happens to the address when you delete a zip code. You don't want the address gone, but still need a zip code. Probably have to write some custom code so that the user knows this when the delete the zip code.

Some data stores have business logic stored in the engine, others you write that at the front end. I'm sure most of this would be on the front end if it's past widows and orphans.

 

[Mascots]

Ideally, you'll want to store data in any database as strict as possible because

Since you need an address and ZIP, but ZIPs can be changed, the model graph is essentially guaranteeing that both will always be available. This means allowing Core Data to throw an error when you attempt to break the relationship is warranted, and you should probably set Delete Rule to Deny. On the Zipcodes side, it would be set to Nullify to allow them to exist as "orphans", but you shouldn't think of them like that since they are essentially their own entities.

You can swap then delete, but never delete without either creating a new Zip object or finding an existing one.This forces your (and anyone else's) model logic to conform to the model type, fulfilling that guarantee.