Re: Plugins Utilizing Core Data NSManagedObjectContext
Re: Plugins Utilizing Core Data NSManagedObjectContext
- Subject: Re: Plugins Utilizing Core Data NSManagedObjectContext
- From: Mike Abdullah <email@hidden>
- Date: Wed, 21 Nov 2007 11:59:36 +0000
Depending upon the level of performance from the store you require,
you might the consider the rough approach we took in Sandvox. There
are two parts:
1.
So that plugin models don't have to be merged with the main
application model we provide a special kind of managed object that can
accept values for any key. Basically we implement -
undefinedValueForKey: and -setValue:forUndefinedKey: such that the
values are actually kept in an archived NSDictionary. This allows
plugin writers to store whatever data they like without having to
worry about Core Data. They don't have to provide their own managed
object model.
2.
Plugin writers then provide what is known as a "plugin delegate."
This is a non-Core Data object that we automatically hook up to the
equivalent plugin object in the model. It receives various delegate
messages from the model so that the behaviour can be fully controlled.
Mike.
On 18 Nov 2007, at 06:54, Marc Blatt wrote:
Hello Everyone,
I have an app that I want to extend its functionality with plugins
that also provide additional data stored and accessed via Core Data.
The thought is that the app has a standard (primary) persistent
store containing app specific data, besides the user's data. Each
plugin would provide additional functionality, including more
sophisticated app specific data relating to the added functionality
of the specific plugin. Without the specific plugin loaded, the
additional app specific data does not exist. My thoughts are to
create a moc for each plugin that contains the added specific data
and merge it with the primary moc.
By way of example (attempting to make this as simple as possible for
this purpose), let's say my primary app is the department and
employees NSPersistentDocument Core Data tutorial app. The primary
app has two entities, department and employee. Thus, the user can
enter information about a specific department, its employees and
their related manager. Now, let's say that the plugin is called
Indie Contractors and that it adds functionality for tracking
independent contractors that work with and/or are being supervised
by certain employees of a company's specific department. The plugin
would add an IndieContractor entity and functionality to track who
the indie contractor answers to, etc.
Obviously, there would have to be a migration of data from the
original persistent store if a user's document already includes user
data (e.g., employees and departments) prior to adding the plugin.
This could cause a number of problems if multiple plugins are
developed for different added functionality. If, for example,
another plugin were created for brother-sister company related
project tracking (ex., Bro-Sis plugin), then migration would need to
be handled for three different scenarios--migration of data for
purchasers of Bro-Sis plugin alone, Indie Contractors alone, and
combined Bro-Sis Indie Contractors plugins. This would become
exponentially impractical if more plugins are added. Not to mention
reversion of data to the original primary persistent store if the
user decides they don't need the added functionality (e.g., trial
users). Please remember, this is only a simplified example of the
added app specific data.
The more I write, the more I come to the conclusion that providing
different versions of the app may be best. But, before starting down
this path, I thought it would be wise to ask all of you your
thoughts on the road not taken. Can a plugin be used to merge
additional persistent store data to an existing persistent store?
Any thoughts on the feasibility of this approach... Any other
possible approaches?
Thanks,
Marc
_______________________________________________
Cocoa-dev mailing list (email@hidden)
Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden
_______________________________________________
Cocoa-dev mailing list (email@hidden)
Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden