• 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
Re: A CoreData Limitation?
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: A CoreData Limitation?


  • Subject: Re: A CoreData Limitation?
  • From: Raffael Cavallaro <email@hidden>
  • Date: Wed, 18 May 2005 12:00:15 -0400


On May 17, 2005, at 1:03 AM, Arthur Schuster wrote:


If the data model changes over time, that model is, in and of itself, also data and it should be modeled as such.


I think you're going to run into a limitation of the Objective-C runtime here. Specifically, it is possible to load new classes/frameworks at runtime but it is not possible to unload the old ones. That is to say, if your data is modeled as a set of classes, once you load these model classes, you can load new ones, but you can't unload the old ones. You'd have to migrate all data to the new model classes, but you'd be stuck with the old ones unless you periodically forced a restart after which you only loaded the latest version of the model classes. Without restarting this is a potential leak, especially if the model changes frequently.

FWIW, this sort of dynamism is part of the Common Lisp Object System which was specifically designed to allow class definitions to be changed *after* they have already been instantiated and for the existing instances based on the old class definition to be automatically updated to the new definition (new slots - i.e., new instance variables, new class variables, new methods) *while the application is still running*.

Objective-C, though more dynamic than most languages, is still not a fully dynamic O-O language for this very reason. The assumption is that you'll bring your app down, recompile to add the changes, and restart it. You can see why this is a problemĀ  for long running, high availability server applications where you can't stop the world (so to speak), and where reestablishing existing application state after a restart can take a great deal of time. That's why smart people write these sorts of application in common lisp.

Of course, this is not the target application for Cocoa or Core Data. End user GUI apps do not need to run continuously, nor is it a disaster to require an application restart once in a while (such as a version upgrade). So you should probably resign yourself to doing data model changes as intended - by recompiling and restarting your application, and writing any custom user data migration tools (such as importers for previous versions of saved files) as needed.

regards,

Raffael Cavallaro, Ph.D.
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: A CoreData Limitation?
      • From: Bill Bumgarner <email@hidden>
References: 
 >Re: A CoreData Limitation? (From: Bill Bumgarner <email@hidden>)
 >Re: A CoreData Limitation? (From: Arthur Schuster <email@hidden>)

  • Prev by Date: Re: CoreData issue when updating a file format
  • Next by Date: Re: CoreData issue when updating a file format
  • Previous by thread: Re: A CoreData Limitation?
  • Next by thread: Re: A CoreData Limitation?
  • Index(es):
    • Date
    • Thread