Re: Core Data using only one object
Re: Core Data using only one object
- Subject: Re: Core Data using only one object
- From: "Corey O'Connor" <email@hidden>
- Date: Tue, 24 Apr 2007 16:14:56 -0700
On 4/24/07, Steve Israelson <email@hidden> wrote:
For example. I am working on an application to create charts. Almost
exactly the same way QuartzComposer works.
OK.
So I have a variety of items and they have inputs and outputs and can
be connected.
OK. I'll refer to these items as nodes.
So, my thinking is:
1) Put the list of item classes into core data as a set of one entity
type.
"As a set of one entity type" - Why not just have each of the node
classes represented by a seperate entity?
2) Put the list of I/O data types as a set of one entity type.
List of I/O data types per node? I'd presume such a list is dependent
on the node type (Bound at compile time) and some parameters specific
to the node (Possibly bound at runtime).
The problem with this is that it is very complex to wrangle into the
core data entity classes.
Hm. Not sure I see why. Have you thought about creating a Graph entity
that stored a list of node instances and a set of edges between nodes?
It is actually much simpler just to have classes and subclass them
for each entity type (well at least it seems like it would be :) )
You actually have to do the reverse: Define the classes to be
subclasses of NSManagedObject. A NSManagedObject instance will take on
the role of a specific entity according to the description in your
managed object model.
This is what I used in my previous example. The custom subclass
provides message handlers to provide the CGPDFDocumentRef instance
variable but the storage of the path is left up to the NSManagedObject
superclass and accessed via key-value coding. Aside from those having
to create new instances of this object, clients just see these objects
as standard Cocoa objects; no different from usual.
On 24-Apr-07, at 2:55 PM, Corey O'Connor wrote:
> On 4/24/07, Steve Israelson <email@hidden> wrote:
>> Where is that documented?
> Those words are likely not documented exactly, but are implied.
>
>> I have been struggling with trying to figure out when CoreData will
>> make things easier. Trying to figure out if ALL my instance variables
>> can be in CoreData etc. Some clear explanation of how and why to use
>> it in various real work scenarios would be handy.
> Try google for this. There are a variety of examples.
>
> I'll give an (innacurate) stab though: First: CoreData provides a
> persistent storage system. That, in itself is nothing special.The
> advantage of CoreData is that it provides an interface to stored data
> that is equivelent (On many levels) to the interface to an in-memory
> object graph. There are restrictions to what object graphs CoreData is
> effective at providing a persistent storage system for. These are
> detailed somewhere in Apple's docs. Still, for the most part: If it's
> easy to describe the classes and and associations between classes in
> an application with CoreData's managed object model designer then
> CoreData is a good system to use.
>
> Not considering optimization, a metric I use to determine if an
> instance variable should be stored or derivied is to evaluate the data
> flow of dependents. I try only to store the bare minimum of instance
> variables required to reconstruct all the data in memory. For
> instance, I have an application that lets people chop up a PDF
> document. The instance variables of one class are:
> * Path to PDF document
> * CGPDFDocumentRef
> Should I store both of these in a Core Data store? In my case the
> answer is no: Just store the Path variable and reconstruct the other
> lazily.
>
> --
> -Corey O'Connor
_______________________________________________
Cocoa-dev mailing list (email@hidden)
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
--
-Corey O'Connor
_______________________________________________
Cocoa-dev mailing list (email@hidden)
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