|
I'm successfully fetching friendface.json and decoding it into an array of User structs. I'm then iterating over array and building up an array of CachedUser objects (my CoreData entity). But when I call ContentView:
User struct:
Friend struct:
CachedUser Class:
Cached Friend Class:
|
|
I can't remember what it was now... but I seem to remember running into a similar problem on this project. The error was telling me the ID or name that was causing the problem, and when I actually searched the JSON document for that ID or name, it was actually listed twice as a friend for one user or something like that. Maybe it was one of the tags actually that was listed twice for a user? I can't remember exactly what it was now. But looking at the data and finding where the duplication actually was gave a me clue as to how to fix it. |
|
A quick fix if you don't want to search around to find duplicates is to make the below change in your loadData func:
|
|
I figured it out, kind of. Needed to add this line to
I say "kind of" because while it eliminates the error, clearly not all the data is being saved correctly as when fetched I get back a lot of records with "Unknown Name". |
|
I've figured out the problem, but not a great solution. The issue is that I had linked both the The reason I was doing it this way was an attempt to batch the save, so instead of calling save 100 times, I call it once on the array of 100 I tried declaring
I thought this would keep what would become the elements in the array detached from the context until being appended to I'm sure there's a way to batch save, but I'm just not seeing it yet. I'm also still not clear on why the extra records were all nil. |
|
@Legion shares a strategy:
I tend to remember reading that this type of optimization is mostly unnecessary. Swift code is optimized internally to perform similar tasks. (I'll need more time to find a source.) For example, you may have 100 view structs in your main view. You call code which may cause some of the view structs to redraw themselves. You may think it wise to write code that only identifies the few that actually change, so that all 100 views are not needlessly redrawn. However, SwiftUI is already ahead of you and will actually only update those views (and small parts of the screen) that are updated. Similarly, I think (Donny Wals?) noted that while your app may "save" dozens of transactions, CoreData efficiently manages the actual write-to-disk strategy to minimize the impact on the system. I wonder if our CoreData gurus have real world experience with this? Seems to me this is one of the test cases that would be great to expose with Xcode's Instruments application. |
|
How did you get the methods under the //MARK to generate? // MARK: Generated accessors for friend |
SPONSORED Take the pain out of configuring and testing your paywalls. RevenueCat's Paywalls allow you to remotely configure and A/B test your entire paywall UI without any code changes or app updates.
Sponsor Hacking with Swift and reach the world's largest Swift community!
This topic has been closed due to inactivity, so you can't reply. Please create a new topic if you need to.
All interactions here are governed by our code of conduct.
Link copied to your pasteboard.