• 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: CoreData modeling a mutable attribute set for an entity
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: CoreData modeling a mutable attribute set for an entity


  • Subject: Re: CoreData modeling a mutable attribute set for an entity
  • From: Jesse Grosjean <email@hidden>
  • Date: Tue, 3 Jan 2006 13:57:26 -0500

I'm not sure, but it's possible that Core Data inheritance isn't the right choice. I haven't used it, but I remember that under EOF, use of inheritance was discouraged, though I don't know the reasoning behind that.

Perhaps you should pick a single attribute type to use for your concrete attribute, and then create transient attributes to translate it into other values. Do you intend for @"2" to be different from 2.0 for some reason? Can't you just use strings for both key and value?

Thanks, I hadn't thought of this and it might just be the answer. At the application level I want the attributes typed, but I guess they don't need to be typed at the CoreData level. Is their anything essential that I'll miss when I bypass the CoreData type system in this way? Here's the things that I can think of, please let me know if there is some essential thing that CoreData's type system does that I'm missing:


- I'll now be responsible for turning object values (like dates) into query-able strings.
- I'll have to type-check the values before turning them into strings (so that a date doesn't end up in a column that's typed for strings)
- It looks like I'll have to only pass string query terms to predicateWithFormat:


I'm not sure what exactly your needs are, but I'm guessing that you're setting yourself for some significant headaches on this path :-/

My specific needs are to allow users of my notebook application (google "Mori notebook" ) to add their own custom columns. This allows them to associate new attributes with their notebook entries. OmniOutliner has a similar "add column" feature that you might be more familiar with.


Thanks,
Jesse
_______________________________________________
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


  • Follow-Ups:
    • Re: CoreData modeling a mutable attribute set for an entity
      • From: Jeff LaMarche <email@hidden>
References: 
 >CoreData modeling a mutable attribute set for an entity (From: Jesse Grosjean <email@hidden>)
 >Re: CoreData modeling a mutable attribute set for an entity (From: Jeff LaMarche <email@hidden>)
 >Re: CoreData modeling a mutable attribute set for an entity (From: Jesse Grosjean <email@hidden>)
 >Re: CoreData modeling a mutable attribute set for an entity (From: Jeff LaMarche <email@hidden>)

  • Prev by Date: NSManagedObjects at Launch
  • Next by Date: Re: Problem with linking against a private framework
  • Previous by thread: Re: CoreData modeling a mutable attribute set for an entity
  • Next by thread: Re: CoreData modeling a mutable attribute set for an entity
  • Index(es):
    • Date
    • Thread