0

In updating an application with Core Data, a new functionality is a async process to synchronize informations between the app and the backend.
The problem is that in the app some NSManagedObject are built while doing a wizard process, at the end of the wizard the user can "save" or "discard" .
This means that the if the synchronization process is made during a wizard some objects can be saved to the persistent store with incomplete data and they "can't" be discharged (due to the save call at the the end of sync).
In the older version it wasn't an issue since the sync was a manual process.
I'm thinking about different solutions, the simplest is to delete the object if the user press cancel at the end or during the wizard, but I'm wondering if there is another better solution that can be useful in other similar cases. I've found this question related to the issue:

  1. How to Deal with Temporary NSManagedObject instances?
  2. How to use Core Data models without saving them?

In the first question the suggestion is to leave the managed object context to nil while creating an NSManagedObject instance and adding its value before saving the object, but reading the comments it doesn't seems to work well, probably when your object has also some relationship with objects that have a managed object context and mine would.
Someone says also to create a child managed object context, but M. Zarra seems to not liking it ( and if you bought a Core Data book, you know that Marcus knows "something" about Core Data)
The second suggests to create an in-memory new store, but it doesn't explain how to move the object from one to another, I'm guessing a sort of copy would be fine.

Which one could be the best approach? I'm looking to a minimum refactoring and regression solution.

Community
  • 1
  • 1
Andrea
  • 26,120
  • 10
  • 85
  • 131
  • You have not explained why you can't delete the objects that you create during the Wizard process. – Duncan Groenewald Sep 07 '15 at 09:11
  • @DuncanGroenewald the problem is that in the in the future I will probably need to add more temp or "to be confirmed" objects, so I'm looking for a more reliable solution. – Andrea Sep 08 '15 at 06:51
  • 1
    Sure but why not create them in the database and simply mark them with a status flag to indicate whether they have been confirmed or not. That way they will survive a shutdown of the app as well. – Duncan Groenewald Sep 08 '15 at 09:43
  • @DuncanGroenewald neat! it seems a good idea. – Andrea Sep 08 '15 at 10:28

0 Answers0