Difference in relationships storage between various storage options (CoreData)
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