Thanks for the suggestion Keary, but some view controllers only load portion of the whole graph.
For example, in the home screen, I show a list of clubs, and when a user taps a club, I show its members. Showing members shouldn’t wipe out the whole graph, but I do would like to make sure its members are empty before I import its member json. > On 21 Mar 2018, at 11:46 PM, Keary Suska <[email protected]> wrote: > > Why not just use a different persistent store instance each time? An > in-memory store shouldn’t be terribly expensive to create, and you can either > keep or dispose of other stores as you need. > > Keary Suska > Esoteritech, Inc. > "Demystifying technology for your home or business" > >> On Mar 21, 2018, at 7:40 AM, Glen Huang <[email protected] >> <mailto:[email protected]>> wrote: >> >> Thanks for the suggestion Alex. >> >> I’m not sure making attributes transient would work though, because the >> objects themselves would still be persisted, you can still save the context >> and fetch them back, only that they don’t contain any attributes, if I’m not >> wrong. >> >> By refreshing the object graph, do you mean updating managed objects instead >> of deleting and creating? I thought about that, but it seems something quite >> difficult to do, because I have to compare the json with the graph and >> figure out what should be created/deleted/updated, and it still requires me >> to create the graph from scratch when the store is empty. That’s why I’m >> looking for ways to have a clean sheet before importing json, so I only have >> one way to manage the object graph (tear down and create from scratch). >> >>> On 21 Mar 2018, at 9:27 PM, Alex Finkel <[email protected]> wrote: >>> >>> if you dont want to persist anything, why not make all the attributes >>> transient? But I would still persist, and just refresh the object graph >>> with the response based on how often the data may change. >>> >>> On Wed, Mar 21, 2018 at 4:56 AM, Glen Huang <[email protected] >>> <mailto:[email protected]><mailto:[email protected] >>> <mailto:[email protected]>>> wrote: >>> Hi, >>> >>> I'm using Core Data as my model, but I don't want to actually persist >>> anything. Anytime a view controller is shown, I load json data from my >>> server and populate the store. >>> >>> The problem is that objects in Core Data persist between view controllers, >>> even with in-memory store type. But when I load json data, I’d like to have >>> a fresh start. So it seems I need to remove existing objects first. >>> >>> You might say I shouldn't use Core Data in this case, just use vanilla >>> objects. But Core Data solves lots of problems, like no need to worry about >>> memory leak for circular dependencies (my model is pretty complex, lots of >>> many-to-many relationships etc), NSFetchedResultsController, etc. And with >>> vanilla objects, when you have a many-to-many relationship, it’s seems it’s >>> impossible to prevent memory leak: >>> >>> class Club { >>> var people: [Person] >>> } >>> class Person { >>> var name: String >>> var clubs: [Club] >>> } >>> >>> Array in swift always create strong reference if I’m not wrong, and the two >>> arrays can create circular references. >>> >>> If I go with Core Data, to easily delete objects and have a fresh start, >>> one solution involves carefully setting up delete rule between object >>> models and then deleting ones at the level I want, and hope it could >>> cascade throughout, but the problem is that this approach is very error >>> prone. If I misconfigure some delete rules, there won’t be any errors, >>> still leaving some objects in the store. >>> >>> I wonder what’s the best way to create object graph in swift without the >>> risk of leaking memory, if Core Data is the way to go, is there any better >>> way to easily detect objects that I forgot to delete? Or is there a better >>> way that I can guarantee that the store is clean before importing json data? >>> >>> Best, >>> Glen >>> _______________________________________________ >>> >>> Cocoa-dev mailing list ([email protected] >>> <mailto:[email protected]> <mailto:[email protected] >>> <mailto:[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 >>> <http://lists.apple.com/> <http://lists.apple.com/ >>> <http://lists.apple.com/>> >>> >>> Help/Unsubscribe/Update your Subscription: >>> https://lists.apple.com/mailman/options/cocoa-dev/finkel.alex%40gmail.com >>> <https://lists.apple.com/mailman/options/cocoa-dev/finkel.alex%40gmail.com><https://lists.apple.com/mailman/options/cocoa-dev/finkel.alex%40gmail.com >>> >>> <https://lists.apple.com/mailman/options/cocoa-dev/finkel.alex%40gmail.com>> >>> >>> This email sent to [email protected] <mailto:[email protected]> >>> <mailto:[email protected] <mailto:[email protected]>> >>> >> >> _______________________________________________ >> >> Cocoa-dev mailing list ([email protected] >> <mailto:[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 >> <http://lists.apple.com/> >> >> Help/Unsubscribe/Update your Subscription: >> https://lists.apple.com/mailman/options/cocoa-dev/cocoa-dev%40esoteritech.com >> >> <https://lists.apple.com/mailman/options/cocoa-dev/cocoa-dev%40esoteritech.com> >> >> This email sent to [email protected] >> <mailto:[email protected]> _______________________________________________ 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]
