Re: NSInMemoryStoreType: Not really persistent, is it?
On Oct 21, 2008, at 6:53 PM, Bill Bumgarner wrote: 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 -- typically an XML RPC of some type -- that wants to take full advantage of CD's object graph management infrastructure. The various change hooks on the MOC and coordinator make it possible to easily mirror the changes out to the wire protocol or update the local cache -- the in memory persistent store -- with changes pulled from the other side. I've been using the in-memory persistent store for unit testing a lot lately. In setUp and tearDown, I create and destroy a full core data stack with an in-memory store. It's very fast, and you're guaranteed a clean slate for each unit test. -Dave ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) 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]
Re: NSInMemoryStoreType: Not really persistent, is it?
(I did a little demo app at one point long ago that used an in memory store to cache results from Amazon's web services API. The front end was all pure Cocoa / bindings / CD with a minimal amount of additional code to pull data from amazon and push it into the local store). Is that demo available some place? Pierre ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) 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]
Re: NSInMemoryStoreType: Not really persistent, is it?
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 (Cocoa-dev@lists.apple.com) 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]
NSInMemoryStoreType: Not really persistent, is it?
An NSPersistentStore created with NSInMemoryStoreType is in volatile RAM or VM, and is therefore not what I would call persistent. So, why is it an NS^Persistent^Store? My guess is that NSInMemoryStoreType was added too late in the development of Core Data to change the names of the NS___Store and NS___StoreCoordinator. Is there a better explanation? (I'm just trying to understand the terms here.) Jerry Krinock ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) 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]
Re: NSInMemoryStoreType: Not really persistent, is it?
On Oct 21, 2008, at 4:43 PM, Jerry Krinock wrote: An NSPersistentStore created with NSInMemoryStoreType is in volatile RAM or VM, and is therefore not what I would call persistent. So, why is it an NS^Persistent^Store? My guess is that NSInMemoryStoreType was added too late in the development of Core Data to change the names of the NS___Store and NS___StoreCoordinator. Is there a better explanation? (I'm just trying to understand the terms here.) 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. 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 -- typically an XML RPC of some type -- that wants to take full advantage of CD's object graph management infrastructure. The various change hooks on the MOC and coordinator make it possible to easily mirror the changes out to the wire protocol or update the local cache -- the in memory persistent store -- with changes pulled from the other side. (I did a little demo app at one point long ago that used an in memory store to cache results from Amazon's web services API. The front end was all pure Cocoa / bindings / CD with a minimal amount of additional code to pull data from amazon and push it into the local store). b.bum smime.p7s Description: S/MIME cryptographic signature ___ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) 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]
