• 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: Cocoa Technologies Back-Story?
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Cocoa Technologies Back-Story?


  • Subject: Re: Cocoa Technologies Back-Story?
  • From: Bill Bumgarner <email@hidden>
  • Date: Tue, 3 May 2005 08:44:01 -0700

On May 3, 2005, at 1:39 AM, Marcel Weiher wrote:
On 2 May 2005, at 16:57, Bill Bumgarner wrote:
Also, I'd pull "Industrial Controller" as a lot of that particular problem is often focused on storing a boatload of relatively simple and regular data to be fed to the machine.

Do you mean that CoreData should be seen as a simplified modelling mechanism, to be used when a fully-fledged OO model isn't required?

Not at all. Core Data works very well for handling large amounts of simple data [a handful of entities with lots of simple attributes]. It also works quite well for more complex models, including object graphs that rely heavily upon inheritance and fairly complex relationships.


The types of relationships and attributes managed "out of the box" by Core Data are relatively simple. For relationships, you can point- and-click model to-one and to-many relationships that are unordered and, optionally, have inverses, min/max counts, and delete rules. Similarly, attributes can be p-and-c modeled as an integer, decimal, double, float, string,boolean, date, or binary data type.

Core Data provides all of the API necessary to build models that express more complex relationships and arbitrary attributes, but it requires a little bit of coding on the developer's part.

For example, if you want to model an object that has an NSColor attribute, you could do something like:

- create a colorData attribute and derived attribute that returns the NSColor. Whenever the derived attribute is changed, write the archived version of the color to colorData via KVC

- create a red/green/blue attribute and do the same as with colorData, but split the color up into its components. This has the advantage that you can query for objects with a color that has certain red/green/blue values. A Hue/saturation/value colorspace may be more useful for queries in that you can then query on Hue to look for a particular color or range of colors.

Or, if you want to have a fixed set of colors with relationships to the colors such that you can answer the "all objects that are red" question by following a relationship:

- create a color Entity with a color attribute as described above

- create relationships w/inverses to the color Entity



_______________________________________________
Do not post admin requests to the list. They will be ignored.
Cocoa-dev mailing list      (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden


References: 
 >Re: Cocoa Technologies Back-Story? (From: Scott Stevenson <email@hidden>)
 >Re: Cocoa Technologies Back-Story? (From: Bill Bumgarner <email@hidden>)
 >Re: Cocoa Technologies Back-Story? (From: Marcel Weiher <email@hidden>)

  • Prev by Date: Re: Spotlight -- Metadata importer vs file package containing rtfd files
  • Next by Date: Re: SearchKit and Spotlight
  • Previous by thread: Re: Cocoa Technologies Back-Story?
  • Next by thread: Re: Cocoa Technologies Back-Story?
  • Index(es):
    • Date
    • Thread