I am doing something very similar to you. I have an application-based
library of potatoes, and each document has a copy of some of those
potatoes. I did this because the document may be opened on another
computer that does not have access to the same library (or as you
mention, the library can change over time, but the document should
not change unless someone has explicitly changed it.)
An added complication in my case is that when one opens the document,
I need to compare the document's potatoes to the library's potatoes
and give the user the opportunity to update the document, the
library, or both if they are not in sync. This means comparing all
the potato attributes for each potato in the document against those
in the library. This can be very time consuming if it is not
optimized well, but it is certainly doable in Core Data.
Another set of complications is: What happens if the user changes the
application library while a document is open? Will they expect the
document to be automatically updated? If so, should the document be
updated immediately, or only after saving changes to the application
library?
I came up with a concept of "live" versus "archived" documents. If a
document is new or dirty, then it is live and it updates its potatoes
in sync with the persistent store of the application library. If the
document is archived (i.e. it has been opened, but not touched), then
it ignores changes to the library.
But all this should be based on how your users will expect the
application to behave.
Dave
On Dec 20, 2008, at 9:29 PM, Jerry Krinock wrote:
On 2008 Dec, 20, at 17:55, Kyle Sluder wrote:
This doesn't make sense... you don't store arrays in managed object
contexts.
Whoops. Indeed, that does not make sense. I should have said that
there are potatoes inserted into the app's central managed object
context. They're not in an array and not related to any other
entity; they just hang loose in there, fetched when needed, which
is not very often.
So, there's a separate app-wide persistent store, or just a
separate MOC?
Both. The app-wide MOC has its PSC set to the app-wide PSC, which
in turn has a persistent store in the Application Support folder.
Looks OK to me, but having never seen anything like this, I was
wondering if
I'm seeing OK today.
It depends on the semantics you're trying to achieve. If what you
really want is to store a reference to the central Potato, then store
its UUID. If you want to store a copy of the potato, keep doing what
you're doing.
By UUID, I believe you mean [[[self objectID] URIRepresentation]
absoluteString].
I'd considered that, but since it's possible that the source potato
in the central store might go away, indeed I want a copy. I was
thinking that, for portability and robustness, in most cases one
would not want a document to reference an object in an app's
Application Support.
Thank you, Kyle -- I'm starting to see a clearer picture what I'm
doing now.
_______________________________________________
Cocoa-dev mailing list ([email protected])
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:
http://lists.apple.com/mailman/options/cocoa-dev/dave.fernandes%
40utoronto.ca
This email sent to [email protected]
_______________________________________________
Cocoa-dev mailing list ([email protected])
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:
http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com
This email sent to [email protected]
