• 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
Antw: Core Data PersistentStore woes with SQLite
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Antw: Core Data PersistentStore woes with SQLite


  • Subject: Antw: Core Data PersistentStore woes with SQLite
  • From: Elise van Looij <email@hidden>
  • Date: Wed, 15 Nov 2006 13:36:58 +0100

Op 15-nov-2006, om 1:09 heeft Scott Stevenson het volgende geschreven:
If you use SQLite, the tables are created once. If you change your model, the database will be out of sync.


It would, of course, be nice if changing the model made the database "just work," but it's actually not an easy thing from Apple's perspective. I think they've heard loud and clear that it needs to get better, though.

Here's the official doc which describes the situation:

<http://developer.apple.com/documentation/Cocoa/Conceptual/CoreData/ Articles/cdVersioning.html>

Yes, I did read it. From my perspective, there seems to be some confusion between the data contained in a store and the datamodel describing the store. IMHO, the two should be considered as largely separate. Thus, as the Versioning section of the Core Data Programming describes, if you change your store from, for example xml to sqlite, you will need to either migrate / import / send you data from one store to the other or accept the loss of said data.
This is a separate issue from changing the structure of one and the same store. The whole point of having the NSPersistentStoreCoordinator, for instance, is that the ManagedObjectContext doesn't need to know or care where the data is coming from or going to. This encapsulation is broken when one can make changes in the data model when using an xml store but not when using a sqlite store.
But is it really such a problem to fix? I may be missing some Core Data architecture ramifications, but isn't this simply a case of "on change attribute is NSSQLiteStore then ALTER TABLE" (excuse the Applescript-accent)? After all, I was able to work around the problem by manually altering the table in the sqlite store. And Core Data is able to do the same thing by itself when using an xml store. I'm secretly picturing the following scene;
INT. A cubicle somewhere in California
PROGRAMMER A
Hey, Tiger, do you remember uncommenting that one line?
PROGRAMMER B
What line?
PROGRAMMER A
Core Data thingie, updateSQLstore or somewhat like.
PROGRAMMER B
(smacks his forehead)
PROGRAMMER A
Never mind, we'll just roll it into Xcode 2.41 and nobody'll be the wiser.


Elise van Looij

_______________________________________________
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: Antw: Core Data PersistentStore woes with SQLite
      • From: Jim Correia <email@hidden>
  • Prev by Date: Licenser kit for C application developed on Mac platform.
  • Next by Date: Re: How To Create Very Huge Images (2 GB and above)
  • Previous by thread: Re: Licenser kit for C application developed on Mac platform.
  • Next by thread: Re: Antw: Core Data PersistentStore woes with SQLite
  • Index(es):
    • Date
    • Thread