Does core data use inverse relationships for widows?

Discussion in 'iOS Programming' started by 1458279, Feb 21, 2016.

  1. 1458279 Suspended

    1458279

    Joined:
    May 1, 2010
    Location:
    California
    #1
    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?
     
  2. Stella, Feb 21, 2016
    Last edited: Feb 21, 2016

    Stella macrumors 604

    Stella

    Joined:
    Apr 21, 2003
    Location:
    Canada
    #2
    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
     
  3. 1458279 thread starter Suspended

    1458279

    Joined:
    May 1, 2010
    Location:
    California
    #3
    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?
     
  4. Stella macrumors 604

    Stella

    Joined:
    Apr 21, 2003
    Location:
    Canada
    #4
    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.
     
  5. 1458279 thread starter Suspended

    1458279

    Joined:
    May 1, 2010
    Location:
    California
    #5
    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.
     
  6. grandM, Feb 25, 2016
    Last edited: Feb 25, 2016

    grandM macrumors 6502a

    grandM

    Joined:
    Oct 14, 2013
    #6
    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.
    --- Post Merged, Feb 25, 2016 ---
    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.
     
  7. 1458279 thread starter Suspended

    1458279

    Joined:
    May 1, 2010
    Location:
    California
    #7
    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.
     
  8. Mascots, Feb 26, 2016
    Last edited: Feb 26, 2016

    Mascots macrumors 65816

    Mascots

    Joined:
    Sep 5, 2009
    #8
    Ideally, you'll want to store data in any database as strict as possible because

    [​IMG]

    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.
     

Share This Page