Cocoa mail archive
Re: CoreData Best Practices
FROM : Bill Bumgarner
DATE : Sat Apr 30 00:00:03 2005
On Apr 29, 2005, at 1:34 PM, James Clause wrote:
> I'd like some advice on the best way to use CoreData in various
> situations. I'm trying to create a BibTeX manager. The problem I'm
> facing is that BibTeX allows user defined fields and multiple
> authors. The obvious way to handle this is to store multiple authors
> as an NSArray of NSStrings and the user defined fields in an
> NSDictionary. However, these type aren't available as attributes in
> CoreData. The best way I can think of to overcome this is to
> serialize dictionaries and arrays and store them as data attributes.
> This doesn't seem to be a solution and I wondered if anyone else had
> a better one.
To store the authors:
Create an Author entity in your Core Data model and create a
relationship between your existing entity and the Author entity.
Create new Author entity instances, as needed, and relate them to
your -- for lack of a better term -- Paper entity, as needed. If
you are managing multiple Papers, it is likely that any one Author
may be an author of multiple Papers and, therefore, you should use a
fetch specification to grab an existing Author, if present, and
relate that existing Author instead of creating duplicate Authors.
With a reverse relationship from Author -> Paper, you could then ask
an Author for all of its Papers. Core Data will take care of
managing the inverse relationships automatically.
To store the key/value pairs:
Create a KeyValuePair entity that contains a 'key' attribute and a
'value' attribute. Then, create instances of those key/value pairs
and relate them to your Paper entities, as necessary.
Alternatively, you could store the values in a attribute marked as
Binary, then use a derived attribute to archive/unarchive the
dictionary/array into/out-of that attribute. This is suboptimal for
a number of reasons and not really recommended, but can be useful in
certain circumstances.
---
In general, when creating the data model for your application,
consider using managed objects for any place that you think you might
need an NSArray or NSDictionary. An NSArray implies a
relationship. NSDictionary implies an alternative form of data
storage and is not hard to push into Core Data.
b.bum
DATE : Sat Apr 30 00:00:03 2005
On Apr 29, 2005, at 1:34 PM, James Clause wrote:
> I'd like some advice on the best way to use CoreData in various
> situations. I'm trying to create a BibTeX manager. The problem I'm
> facing is that BibTeX allows user defined fields and multiple
> authors. The obvious way to handle this is to store multiple authors
> as an NSArray of NSStrings and the user defined fields in an
> NSDictionary. However, these type aren't available as attributes in
> CoreData. The best way I can think of to overcome this is to
> serialize dictionaries and arrays and store them as data attributes.
> This doesn't seem to be a solution and I wondered if anyone else had
> a better one.
To store the authors:
Create an Author entity in your Core Data model and create a
relationship between your existing entity and the Author entity.
Create new Author entity instances, as needed, and relate them to
your -- for lack of a better term -- Paper entity, as needed. If
you are managing multiple Papers, it is likely that any one Author
may be an author of multiple Papers and, therefore, you should use a
fetch specification to grab an existing Author, if present, and
relate that existing Author instead of creating duplicate Authors.
With a reverse relationship from Author -> Paper, you could then ask
an Author for all of its Papers. Core Data will take care of
managing the inverse relationships automatically.
To store the key/value pairs:
Create a KeyValuePair entity that contains a 'key' attribute and a
'value' attribute. Then, create instances of those key/value pairs
and relate them to your Paper entities, as necessary.
Alternatively, you could store the values in a attribute marked as
Binary, then use a derived attribute to archive/unarchive the
dictionary/array into/out-of that attribute. This is suboptimal for
a number of reasons and not really recommended, but can be useful in
certain circumstances.
---
In general, when creating the data model for your application,
consider using managed objects for any place that you think you might
need an NSArray or NSDictionary. An NSArray implies a
relationship. NSDictionary implies an alternative form of data
storage and is not hard to push into Core Data.
b.bum
