In that case the only way to avoid having to remove objects first, that I can think of, is to create your own custom persistent store. It’s not too hard, and might be a better solution in the long run anyway.
Keary Suska Esoteritech, Inc. "Demystifying technology for your home or business" > On Mar 21, 2018, at 9:52 AM, Glen Huang <hey...@gmail.com> wrote: > > 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 <cocoa-...@esoteritech.com> 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 <hey...@gmail.com> 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 <finkel.a...@gmail.com> 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 >>>> <hey...@gmail.com<mailto:hey...@gmail.com>> 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 (Cocoa-dev@lists.apple.com >>>> <mailto:Cocoa-dev@lists.apple.com>) >>>> >>>> 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/finkel.alex%40gmail.com<https://lists.apple.com/mailman/options/cocoa-dev/finkel.alex%40gmail.com> >>>> >>>> This email sent to finkel.a...@gmail.com <mailto:finkel.a...@gmail.com> >>>> >>> >>> _______________________________________________ >>> >>> Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) >>> >>> 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/cocoa-dev%40esoteritech.com >>> >>> This email sent to cocoa-...@esoteritech.com > _______________________________________________ Cocoa-dev mailing list (Cocoa-dev@lists.apple.com) 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 arch...@mail-archive.com
