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 16:53:15 -0700
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?
Well, what I meant was I have an entity type called "GraphicNode" and
it has attributes that are used to describe this node class.
The user will make use of instances of the class these describe,
probably by me calling a factory method to create a new node.
These can't all be different types of entities because how would my
code ever collect em all up into a palette to provide a list of
things for the user to drag into their document?
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).
This list is descriptive. Each class above would describe in a
general way how many possible inputs there could be and whay type it
is by linking its type relationship to one of these guys.
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?
The stuff above describes the template objects available to the user
to make their document.
The document itself would have a collection of something else to
describe it, something like you describe.
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.
I was considering this, but once I started going there I was asking
myself what the heck CoreData was giving me then?
This is the basics behind my original comment. How and why to use
CoreData and some REAL world examples, not simplistic ones.
I have one app with probably 50 different entity types all
interconnected in complex ways, and I ask myself if this is sanity or
not.
_______________________________________________
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