• Open Menu Close Menu
  • Apple
  • Shopping Bag
  • Apple
  • Mac
  • iPad
  • iPhone
  • Watch
  • TV
  • Music
  • Support
  • Search apple.com
  • Shopping Bag

Lists

Open Menu Close Menu
  • Terms and Conditions
  • Lists hosted on this site
  • Email the Postmaster
  • Tips for posting to public mailing lists
Re: Core Data Questions
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Core Data Questions


  • Subject: Re: Core Data Questions
  • From: William Turner <email@hidden>
  • Date: Sat, 07 Jun 2008 00:45:29 -0700

Hi Gordon,

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?

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).

Wil

On Jun 6, 2008, at 5:06 PM, Gordon Apple wrote:

Our data hierarchy has six objects, all of which inherit from "BaseList"
which contains a dictionary (props) and an array (subList). These lists are
chained (i.e., the six subclasses). So in the first-attempt data model,
baselist.sublist is a one-to-many looping back to BaseList.


However, the last item in the chain (Layer) needs it's subList to point
to shapes instead of BaseList, i.e., subList is now a draw list. I could
move subList into the subclasses, but there is a lot of recursive stuff
going on in BaseList where it needs to be. Maybe I could just override an
accessor so BaseList can get to it. Apparently, there's an issue calling
"super" in managed objects, so I'll have to see if that poses any problems.


On Fri, Jun 6, 2008 at 6:59 PM, Gordon Apple <email@hidden> wrote:
I'm currently trying to evaluate whether or not Core Data is a viable
storage system in our application. Although I've been through the
tutorials, Refs, and searches, I still have questions:


1. Our data hierarchy model does not seem to fit into the Core Data object
model. (At least I haven't been able to make it fit so far). Now what?
Redo the data model?

This seems unlikely. Can you provide some more information on your model? You may simply be looking at Core Data the wrong way.


_______________________________________________

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


  • Follow-Ups:
    • Re: Core Data Questions
      • From: Gordon Apple <email@hidden>
References: 
 >Re: Core Data Questions (From: Gordon Apple <email@hidden>)

  • Prev by Date: Learning Cocoa with RubyCocoa (was Regular Expressions)
  • Next by Date: FTP framework
  • Previous by thread: Re: Core Data Questions
  • Next by thread: Re: Core Data Questions
  • Index(es):
    • Date
    • Thread