Re: Saving Images with Core Data (i.e., JPEG, TIFF, etc.)

FROM : Scott Ellsworth
DATE : Fri Apr 29 23:32:29 2005

On Apr 29, 2005, at 2:16 PM, mmalcolm crawford wrote:

>
> On Apr 29, 2005, at 1:41 PM, Jim Correia wrote:
>
>

>> On Apr 29, 2005, at 2:37 PM, mmalcolm crawford wrote:
>>

>>> For example, if a Person entity should have a 'photo' attribute, 
>>> then create a Photo entity with just a single attribute -- the 
>>> data -- and if you care a relationship back to the Person 
>>> (typically modeling relationships in both directions is a Good 
>>> Thing).  Then create a relationship from the Person to the Photo 
>>> entity.  This will mean that photo data is only loaded from the 
>>> persistent store if you actually use it.


Watch out for many-many relationships.  They can be a true 
performance killer.

>> Is this true in general (or at least for SQLite stores)? 
>> Relationships are loaded on demand, but attributes are loaded when 
>> the object is?
>>

> Faulting only applies to relationships (so in your example comments 
> will be loaded along with the other attributes on fetch), and is 
> only really relevant if you use a SQLite store since it can fetch 
> data on an as-needed basis.  The other stores -- XML and binary -- 
> both load the whole persistent store into memory when they're 
> accessed.


What about fetched properties?  The docs imply a lazy fetch, but I 
have not had a chance to test.

On the other hand, I am not sure I grok when I would use a fetched 
property, as opposed to a stored fetch request.  Is there an implicit 
"must be in a relatioship with the entity that the fetched property 
is a part of" condition on a fetched property, or some such?

Scott