0

I want to create temporary managed objects and save/discard them conditionally.

The consensus seems to be that I should create a child managed object context and conditionally save/discard it.

In that case, how do I persist one of the temporary entities and discard the rest?

pkamb
  • 33,281
  • 23
  • 160
  • 191
Aykhan Hagverdili
  • 28,141
  • 6
  • 41
  • 93
  • 1
    When you save a child context, all of the objects in it are persisted to its parent. A child managed context doesn't really help you save one entity and discard the rest. You still need to delete the ones you don't want to save. It is cleaner than using the main managed object context as it at least localises the add/delete effects. You don't need to be concerned that some other code might save the context, committing your changes prematurely. Depending on what you are trying to do perhaps you could create many child contexts, each with one object and save the child that you want to keep. – Paulw11 Sep 20 '21 at 12:39
  • @Paulw11 I did consider creating one context per element. I might have a couple thousand temporary elements. Would that approach be practical then? – Aykhan Hagverdili Sep 20 '21 at 12:42
  • Are you saying you might have a thousand temporary objects but you might only want to save a few of them? – Joakim Danielson Sep 20 '21 at 12:59
  • @JoakimDanielson yes exactly. I want to download and show the user a list of lots of items and they may keep any or all of them. – Aykhan Hagverdili Sep 20 '21 at 13:00
  • 2
    If your model is not that complex (many relationships) I would consider using a struct for the objects you show the user and then only create managed objects from the selected items instead. Since you write that you are downloading items maybe you already have a suitable struct for this. – Joakim Danielson Sep 20 '21 at 13:07
  • I agree. It doesn't sound like creating managed objects is the right approach here. You would typically use that approach where there is a reasonably good chance of saving the object. For example https://cocoacasts.com/the-elegance-of-disposable-managed-object-contexts. I think in your case it is easier to create managed objects for the structs you want to save when you know which ones they are. – Paulw11 Sep 20 '21 at 13:23
  • @Paulw11 yes that is an option to consider. How about creating unassociated objects as shown [here](https://stackoverflow.com/a/3258470/10147399) and conditionally associating them with the context? Comments under that point out that editing unassociated objects crash the app, but I don't happen to edit them until they are saved. It is somewhat error-prone. – Aykhan Hagverdili Sep 20 '21 at 13:27
  • 2
    Better to use a struct then IMO – Joakim Danielson Sep 20 '21 at 17:33
  • @JoakimDanielson I agree. Thank you for your help. – Aykhan Hagverdili Sep 20 '21 at 17:35

1 Answers1

2

Temporary NSManagedObject instances do not need to be associated with a context.

In your situation, create the instances without a context. Pass nil into the instance on creation instead of a child context.

When you are ready to save one of those objects, give it a context and call save on that context.

Reading the comments above, a struct works if you have a high ratio of discard to save. If the situation is reversed (mostly saves) then I would load into MOs and discard. Memory and performance will be the drivers for you.

Aykhan Hagverdili
  • 28,141
  • 6
  • 41
  • 93
Marcus S. Zarra
  • 46,571
  • 9
  • 101
  • 182