I'm making an app where you can have multiple journals and have different settings for each journal. I'm storing the Journal and JournalSettings data in Core Data. Now I want to allow the user to edit the default journal settings so that new Journals have the JournalSettings described by the default journal settings. I'm using UserDefaults to store the default journal settings because it seems like an appropriate place to store defaults. I already have a JournalSettingsView to display a JournalSettings object, and I would like to reuse this view to display and edit the default journal settings. So I want to create a JournalSettings instance from the default journal settings data stored in UserDefaults, but I don't want to save this new JournalSettings instance to Core Data because it would just be a copy of data already stored in UserDefaults.

Can I can create a Core Data object instance without ever saving it to Core Data? I thought I might be able to use a in-memory child NSManagedObjectContext that I would create the JournalSettings corresponding to the default journal settings in, but from what I understand, that child context would then save to its parent context (my main Core Data context). I also tried to create a separate (not a child) in-memory NSManagedObjectContext to store the default JournalSettings, but then my app crashes with the error:

Multiple NSEntityDescriptions claim the NSManagedObject subclass 'JournalSettings' so  entity is unable to disambiguate.

If I can't create a Core Data object without saving it, there are a few ways I can still implement the default journal settings, but I'm not sure which would be best practice:

1. Move default journal settings into Core Data. This would work well; UserDefaults just seems like a more appropriate place to store defaults.
2. Create a new view to show/edit the default journal settings, instead of reusing JournalSettingsView. This would also work, but it would be a little annoying to manage two views that are meant to show the same thing. The only real difference between the views would be that one gets its input as a JournalSettings instance, while the other would be fed JournalSettings attributes (like font size, journal name, etc.) individually.

CodePudding user response：

Child context is solution you are looking for.

From documentation:

If a context’s parent store is another managed object context, fetch and save operations are mediated by the parent context instead of a coordinator. This pattern has a number of usage scenarios, including:

• Managing discardable edits, such as in an inspector window or view.

You are right that when you save child context data changes will propagate to parent context.
In your case you don't need to save child context at all.

Related to your other ideas:

1. Which storage is suited best: UserDefault or CoreData. It depends on what type of settings JournalSettings represent. If it's data related settings (as reference data objects and etc) I would store in CD. But if it's general settings that are data independent than UD is better place. And do not forget that UD can't be purged by system / lost. So you should never store sensitive / important data in it.
2. Maybe you don't need to create a new view. Instead you may extract data related operations in another entity (Controller in MVC, ViewModel in MVVM...). In such case you would have single view that independent of storage type.