Re: More Core Data Questions
Re: More Core Data Questions
- Subject: Re: More Core Data Questions
- From: Jon Hull <email@hidden>
- Date: Mon, 12 Oct 2009 13:32:16 -0700
On Oct 12, 2009, at 12:46 PM, I. Savant wrote:
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.
I must have missed this. Thank you.
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.
I have spent the last 48 hours (re)reading core data docs. My head is
swimming in docs. The short answer is yes, I understand to give each
thread it's own context, but I don't know if it will break without a
run loop.
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.
Yes, although I also read a warning about using these cross-stores
somewhere, so I was thinking of rolling my own. The core data UUID
would probably also be temporary with the way I am currently creating
my objects (because I wouldn't have saved yet), so I would need
something persistent.
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.
Yes, well it is fairly complex... but it looks like core data is not a
good fit since a basic requirement is that I need it to store nested
arrays of immutable objects and keep the order (I also need to allow
those objects to be inserted at multiple points in the array). The
immutability and the possibility of multiple entries make an order
property unworkable.
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.
Yes, I did this in the last core data app I wrote.
• Use core data in a rather complex way
What complex way?
Multiple stores + some way of keeping ordered arrays
• 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.
Oh no... I mean instead of core data
• 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.
again instead of core data, but useful to know.
• Something with proxies that go grab it just in time (combined
with SQL or the files above)
I'm not sure what this means.
I could use a proxy to implement lazy loading (from a file or out of
SQL)
• 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.
Thank you. I might consider something like this instead of rolling my
own SQL.
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.
Yes, I have been living those docs for a couple of days now. It now
looks like core data is not a good match for my particular problem.
Thanks for your help.
Thanks,
Jon_______________________________________________
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