Re: More Core Data Questions
Re: More Core Data Questions
- Subject: Re: More Core Data Questions
- From: "I. Savant" <email@hidden>
- Date: Mon, 12 Oct 2009 15:46:09 -0400
On Oct 12, 2009, at 3:31 PM, Jon Hull wrote:
1) Can I count on a to-many relationship keeping the order of the
managedObjects it points to? The order is very important in this
case, and I need a way to ensure that the order does not change when
the object is saved and reloaded.
No. This is stated in the documentation and has come up on this
list many times. You'll want to add a property to keep track of the
desired order.
2) Does core data require a run-loop to work?
I'm not quite sure how to answer that, specifically ...
All of the work takes place in a background thread, and that is the
only thread which would be accessing these objects
... so I'll answer this (what you appear to be asking).
Multithreading with Core Data gets its own section in the
documentation - each thread needs its own context. Read the
documentation.
3) What is the best way of connecting objects from different
stores? I am considering giving them UUIDs and then storing that as
a reference. Then setting a transient property based on that in -
awakeFromFetch. Alternatively, I could store it as a fetched
property, but I want it to be a 1:1 correspondence.
If the objects are already saved to a store, they already have a
stable, unique ID. This is also covered in the documentation and in
the list archives.
4) Is there a better way to get this lazy loading? My main goal is
to keep only those objects from this large (>1000) object graph in
memory that are needed (since the iPhone has limited memory).
You're going to need to be specific about the relevant parts of
your data model fora "best approach" suggestion. General guidelines
are in the docs.
You can always have a separate entity for the large data (to act as
a BLOB). IE, an "Image" entity that holds lots of metadata, possibly a
small thumbnail, and a reference to an instance of "ImageData" that
holds the actual data.
• Use core data in a rather complex way
What complex way?
• Roll my own SQL with a single table that stores blobs by that
identifier (see above) and then returns a freeze dried object from
the blob.
Not possible (or at least remotely sane) with a Core Data created
store. Don't edit the store. Its implementation details (ie, the
schema) are private and subject to change. This is a Bad Idea.
• Store each object as a small file in a folder and use the
identifier in the filename
Also possible if you don't want the data inside the store. You can
create (and archive) an FSRef for more robust "locate-the-moved-file-
between-sessions" behavior.
• Something with proxies that go grab it just in time (combined
with SQL or the files above)
I'm not sure what this means.
• Something I haven't thought of...
You were on the right track with the idea of a BLOB if you don't
mind saving the BLOB in the store. The alternative - which you also
guessed - is to save a reference to an external file. The choice is
yours: neither is better than the other in the general case.
Any help is greatly appreciated!
You can help yourself better than anybody else by (re-)reading the
Core Data Programming Guide. It contains answers to pretty much
everything you've asked here. Very specific answers.
--
I.S.
_______________________________________________
Cocoa-dev mailing list (email@hidden)
Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden