Re: Core Data using only one object
Re: Core Data using only one object
- Subject: Re: Core Data using only one object
- From: Steve Israelson <email@hidden>
- Date: Tue, 24 Apr 2007 15:11:40 -0700
Google, sure. I still don't find what I need.
For example. I am working on an application to create charts. Almost
exactly the same way QuartzComposer works.
So I have a variety of items and they have inputs and outputs and can
be connected.
So, my thinking is:
1) Put the list of item classes into core data as a set of one entity
type.
2) Put the list of I/O data types as a set of one entity type.
3) The user creates a list of items in their document and each one
has a link to one of the items in (1) to determine its class.
4) The user creates a list of connections making use of the items in
(2).
The problem with this is that it is very complex to wrangle into the
core data entity classes.
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 :) )
So, this seems like a good fit, but it also seems like the design of
the entities suddenly becomes very complicated.
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