• Open Menu Close Menu
  • Apple
  • Shopping Bag
  • Apple
  • Mac
  • iPad
  • iPhone
  • Watch
  • TV
  • Music
  • Support
  • Search apple.com
  • Shopping Bag

Lists

Open Menu Close Menu
  • Terms and Conditions
  • Lists hosted on this site
  • Email the Postmaster
  • Tips for posting to public mailing lists
Difference in relationships storage between various storage options (CoreData)
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Difference in relationships storage between various storage options (CoreData)


  • Subject: Difference in relationships storage between various storage options (CoreData)
  • From: Alexander Lamb <email@hidden>
  • Date: Wed, 14 Jun 2006 08:49:28 +0200

Hello list,

This is a comment, not a question. It is rather obvious but may help.

XML and Binary storages store relationships both ways. SQLLite only stores relationships from the "to-one" side.
In other words, if you have an entity "department" and an entity "employee". In the SQLLite store, only the foreign key from employee to department is stored. The to-many relationship is built from a query (as with any relational database).
In the two other store types (and you can check easily by opening in TextEdit the XML one), relationships are both ways. It means the department entity will have a list of employees explicitly given.


Ok, what is the point?

Well, I made a mistake in my code somewhere. I set the "employee.department" correctly, but forgot to do an "addObject" to "employee.departements".

The result was not only my object graph was wrong in memory, but it was also wrong in the file! Even restarting the application (reloading data), I had an employee belonging to a department but a department without that same employee.

The same (wrong) code using SQLLite worked better since after reloading data the object graph was correct again.

So, the conclusion?

With XML or Binary stores, a simple mistake in relationships handling can corrupt relationships.
With SQLLite, data integrity is preserved.


XML or Binary stores are therefore good for development (you rather quickly see where things have gone wrong).
SQLLite is probably safer to ship (or deploy) code. A mistake in your code will less easily corrupt your data.


A suggestion (maybe it has already been said): it would be nice to have a tool which rebuilds relationships in XML or Binary stores.

Alex
--
Alexander Lamb
email@hidden



_______________________________________________
Do not post admin requests to the list. They will be ignored.
Cocoa-dev mailing list      (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden


  • Follow-Ups:
    • Re: Difference in relationships storage between various storage options (CoreData)
      • From: Chris Hanson <email@hidden>
  • Prev by Date: Embedding a color item in an NSTableView
  • Next by Date: Doc App - Errors closing an document.
  • Previous by thread: Re: Embedding a color item in an NSTableView
  • Next by thread: Re: Difference in relationships storage between various storage options (CoreData)
  • Index(es):
    • Date
    • Thread