On Dec 15, 2016, at 7:24 PM, Daryle Walker <[email protected]> wrote: > > On Dec 6, 2016, at 10:18 PM, Chris Hanson <[email protected] <mailto:[email protected]>> > wrote: >> >> On Dec 5, 2016, at 4:18 PM, Daryle Walker <[email protected] >> <mailto:[email protected]>> wrote: >> >>> I've heard that Core Data is a object graph and persistence library. What >>> if you want just the first part? The graph seems like a neat way to save >>> on modeling code, the external format is not database-ish at all (so the >>> capability for custom export formats won't help). Can I just not use the >>> persistence part and use custom save & load functions? Or do I have to (or >>> should) give up on Core Data? >> >> This is exactly the sort of thing that subclassing NSAtomicStore >> <https://developer.apple.com/reference/coredata/nsatomicstore> lets you do. >> >> There are only a few methods to override, and then you can just use one of >> your own documents as if it were one of the built-in persistent store types. > > I have looked into that, that’s why I wrote in: > >>> the external format is not database-ish at all (so the capability for >>> custom export formats won't help) > > The store format assumes there’s at least one field in a record that can be > used like a database(-ish) index. Custom stores can’t help if the data is > too dumb to have such a qualifying field.
What do you mean? Most atomically read/written file formats should be supportable as an NSAtomicStore. Object IDs can be purely an in-memory construct for such a store, for example based on the order an object was (initially) read or instantiated. -- Chris _______________________________________________ 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: https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to [email protected]
