> If you're designing a data model using Core Data, it's actually very
> useful to step back and look at your data the way a layperson would.
> By this I mean forget about classes and inheritance and all that
> stuff. You can come back to it later, but the main thing is to look at
> the problem in terms of "I'm trying to model these objects and they
> have these properties and interact with each other in these ways." It
> turns out that traditional OOP class inheritance and CD entity
> inheritance are significantly different. In fact, avoid entity
> inheritance unless you know that you will need to do fetches that
> return objects of different entity types - otherwise it's just not a
> good performance tradeoff.
>
> Given that, could you describe your data in terms that don't impose
> specific design choices?
We probably should have started with CoreData, but I started as a Cocoa
newbie and was having enough difficulties without delving into that. Now,
the software is fairly far along and I'm looking at a retrofit, possibly
using CoreData. In the original version, years ago, I used Bob Krause's
NeoAccess for persistent store. After that went away, I figured we would
migrate the new version to PostgreSQL, which we still might do. However,
we're considering some other products using much of the same code base, were
CoreData might make more sense because it wouldn't require a user-install of
PostgreSQL (yes, I do know about BaseTen).
The data root is the Course object, followed by Sessions, etc. down to
the Layer drawList. Obviously, this will eventually be a massive amount of
data, only a small portion of which needs to be in RAM at any one time.
However, there are a variety of time-management routines which need to
frequently scan much of the hierarchy, but only need to retrieve full
content data in the neighborhood of the current time. All object ivars
(except the array for the next lower-level), including those of Shapes,
reside in dictionaries. These have certain required properties plus many
optional properties, some not currently defined and some possibly not even
know to the containing object.
> What is the issue in NSManagedObject with regards to calling super?
> It's actually recommended that you invoke super for a number of
> methods in the class (awakeFromFetch, validateForDelete, and others).
>
Probably just my not understanding the CoreData.pdf (p.49) docs:
"If you have two subclasses of NSManagedObject where the parent class
implements a dynamic property
and its subclass (the grandchild of NSManagedObject) overrides the methods
for the property, those
overrides cannot call super. "
_______________________________________________
Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)
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:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com
This email sent to [EMAIL PROTECTED]
