Re: NSInMemoryStoreType: Not really "persistent", is it?
Re: NSInMemoryStoreType: Not really "persistent", is it?
- Subject: Re: NSInMemoryStoreType: Not really "persistent", is it?
- From: Jerry Krinock <email@hidden>
- Date: Wed, 22 Oct 2008 11:21:18 -0700
On 2008 Oct, 21, at 16:53, Bill Bumgarner wrote:
Well, it is persistent. Just don't turn off your machine or shut
down the app.
In all seriousness, a persistent store the interface between the
coordinator and the permanent state of your object graph -- both for
reading and writing. When you push a change into a store, that
change effectively becomes a permanent part of that objects state.
That the actual storage is in memory vs. on disk is irrelevant.
Well, I agree that it has persistent relationships, as long as the
power is not turned off. But since power does get turned off, I think
that instead of NSPersistentStore, and since managed objects have
relationsips, I think Apple should have called it NSObjectStore or
(longer - eek!) NSManagedObjectStore. It would have made more sense
to base these things' name on what they store (managed objects),
instead of on some attribute (their persistence) which is not always
true.
Look, I can store lots of different things in our refrigerator, and
they will persist as long as the power does not go off. So, I could
call it our NSPersistentStore. But calling it NSPerishableFoodStore
would make it easier for the other cooks in the house to understand.
The in memory store is actually extremely useful for caches and as a
backing store for applications that read/write to/from some kind of
server
I'm just hoping that it will Undo/Redo tree-structured data correctly,
always. Even though I've written a ton of code in my old non-Core-
Data app to support Undo/Redo, I can still find pathological sequences
of three or more edit operations for which Undo or Redo won't bring
the data back to the original state. My choices were to either start
almost from scratch and fix my data-structuring mistakes, or start
almost from scratch and use Core Data.
_______________________________________________
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