• 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: Jeff LaMarche <email@hidden>
  • Date: Tue, 3 Jan 2006 14:47:22 -0500


On Jan 3, 2006, at 1:57 PM, Jesse Grosjean wrote:
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:

You don't necessarily have to "bypass" core data - you can use transient, non-standard attributes to make the value available as other data types. Core Data will manage the state of the transient attributes, but just won't save them to disk. You can read more about this here:


http://developer.apple.com/documentation/Cocoa/Conceptual/CoreData/ Articles/cdNSAttributes.html


- I'll now be responsible for turning object values (like dates) into query-able strings.

Hmmm.... I'm not sure if you can query on transients or not...

- 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:

Again, I'm not sure about how fetch requests work with transient attributes, sorry :(


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.

Do you have to be able to specify the "type" of column, or can you just change the way it's displayed using formatters? It's not horribly inefficient to store most things (except binary data) as a string, so unless they're going to be storing very large items, why not just assume it's always a string and then just change how you display and input the values in the interface?


Jeff

_______________________________________________
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: 
 >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>)
 >Re: CoreData modeling a mutable attribute set for an entity (From: Jesse Grosjean <email@hidden>)

  • Prev by Date: Re: Problem with linking against a private framework
  • Next by Date: Re: Text height for printing (fixed width)
  • 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