• 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: Core Data: Working with multiple models
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Core Data: Working with multiple models


  • Subject: Re: Core Data: Working with multiple models
  • From: Adam Knight <email@hidden>
  • Date: Mon, 6 Nov 2006 15:36:54 -0600

On Nov 5, 2006, at 3:13 AM, Martin Köhler wrote:
Hi,

In XCode, let's say I have
	- a framework project "Framework"
		- with a model "FrameworkModel"
			- comprising an entity "FrameworkEntity"
	- an application project "Application"
		- with a model "ApplicationModel"
			- comprising an entity "DocumentPartEntity"

So now I want that "DocumentPartEntity" aggregates "FrameworkEntity".

Let's assume "Framework" is not aware of "Application", but "Application" is aware of "Framework".


What's the "best practice" to realize this "linkage" between two models?
- programmatically merge both models and add a relationship property to "DocumentPartEntity", which aggregates "FrameworkEntity"?
- or is there a simpler way? Perhaps even a trick to "link" them together in XCode?

That's a very open question and possibly dangerous idea. Something to consider: While you _can_ manually load the framework's MOM from within the application and change the application's MOM to link to the defined entity, this could pose some problems with your application as this has to happen before you setup the context or otherwise use the application's MOM. That's not a big problem, and is possible, but it's added complexity. Then, once done, any file saved will only be accessible afterwards if you have the exact same set of frameworks (and, thus, composite model) loaded.


A better idea would be to have a generic entity that any relevant frameworks could store their data in (just store the framework name and a key and value, etc.) and create an API to access that from the framework. Not as clean on the usability side, but more standard and it doesn't open you up to model and file difficulties later on.

Just a thought. I don't know your project so it might be wildly infeasible. That said, if you want to go the direction you're heading, the solution you list is the answer.

--
Adam Knight
codepoetry - http://www.codepoetry.net/products/



_______________________________________________
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


References: 
 >Core Data: Working with multiple models (From: Martin Köhler <email@hidden>)

  • Prev by Date: CMSCreateDataProviderOrGetInfo : Invalid colorspace type
  • Next by Date: Re: Core data "now"
  • Previous by thread: Core Data: Working with multiple models
  • Next by thread: Indicate loading while bindings read from Core Data
  • Index(es):
    • Date
    • Thread