Shakedown Social

0 posts0 participants0 posts today

Aleksander StojanowskiIf that fails, I’ll switch to <a href="https://iosdev.space/tags/CoreData" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#CoreData</a>, as there are much more materials on how to deal with it, not to mention it’s a mature framework. Now it’s time to at last rest before the new week! ☺️ <a href="https://iosdev.space/tags/BuildInPublic" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#BuildInPublic</a> <a href="https://iosdev.space/tags/IndieDev" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#IndieDev</a> <a href="https://iosdev.space/tags/iOSDev" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#iOSDev</a>

Aleksander StojanowskiAll that made me think, maybe <a href="https://iosdev.space/tags/CoreData" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#CoreData</a> would be a better choice, but at this point I’m a bit afraid to change everything. On the other hand, it’d be better to do it now than after the official release, I guess. <a href="https://iosdev.space/tags/Swift" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#Swift</a> <a href="https://iosdev.space/tags/iOSApp" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#iOSApp</a> <a href="https://iosdev.space/tags/AppDevelopment" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#AppDevelopment</a>

Axel Le Pennec<a href="https://mastodon.social/@helge" class="u-url mention" rel="nofollow noopener noreferrer" target="_blank">@helge</a> <a href="https://hachyderm.io/@groue" class="u-url mention" rel="nofollow noopener noreferrer" target="_blank">@groue</a> <a href="https://mastodon.social/@fatbobman" class="u-url mention" rel="nofollow noopener noreferrer" target="_blank">@fatbobman</a> both async functions are isolated to the same actor (queue?) but it doesn’t mean they will be running on the same thread right? Passing non-Sendable type is ok but I thought the issue with <a href="https://iosdev.space/tags/CoreData" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#CoreData</a> NSManagedObject and <a href="https://iosdev.space/tags/SwiftData" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#SwiftData</a> Model was that they can’t be passed between threads. Which seems to be the case with two async functions in a ModelActor.What do you think <a href="https://mastodon.social/@mattiem" class="u-url mention" rel="nofollow noopener noreferrer" target="_blank">@mattiem</a>?Thanks!

Duncan BabbageSo... I’ve traced my performance issue down to the way I’m updating my main SwiftUI lists in response to incoming `NSPersistentStoreRemoteChange` <a href="https://iosdev.space/tags/CoreData" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#CoreData</a> notifications from iCloud. I was processing them on a background context, then sending notifications observed by lists. If they displayed types that were updated they’d refresh.Clearly I was not doing this well because the view-side-subscription-and-refresh part could cause multi-second UI pauses. Obv not great.Advice welcome. <a href="https://iosdev.space/tags/iOSDev" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#iOSDev</a>

Duncan BabbageIt’s pretty easy to define a <a href="https://iosdev.space/tags/SwiftLang" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#SwiftLang</a> OptionSet & then store it in a <a href="https://iosdev.space/tags/CoreData" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#CoreData</a> Int using a custom getter and setter. Testing suggests it’s possible to fetch based on specific option, i.e. NSPredicate like: `NSPredicate(format: "(%K & %i) != 0", “options”, myOption.rawValue)`…which works great till app crashes during iCloud sync with something like: "Exception was caught during Core Data change processing. [snip] Can't do bit operators on non-numbers with userInfo (null)”Thoughts? <a href="https://iosdev.space/tags/iOSDev" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#iOSDev</a>

Duncan BabbageAnyone got any insight into <a href="https://iosdev.space/tags/CoreData" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#CoreData</a> <a href="https://iosdev.space/tags/iCloud" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#iCloud</a> sync issues when running TestFlight builds?When running dev builds, everything was syncing rapidly between two physical devices. Now with TestFlight builds on three devices, which should be syncing to production iCloud, seeing initial sync but not seeming to sync further updates. Hmm, I presumed that I couldn’t attach a debugger to a TestFlight build… but perhaps that’s wrong? <a href="https://iosdev.space/tags/iOSDev" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#iOSDev</a>

Duncan BabbageCan someone please explain to me the right hand side of the equality `ShoppingItem.entity().name == change.changedObjectID.entity.name` in the code shown in the screenshot?In this code, `change` is an `NSPersistentHistoryChange`, and `changedObjectID` is an `NSManagedObjectID`. Is there some magic way to access an entity from managedObjectID.entity that I am unaware of? NSManagedObjectIDs don’t have properties or methods you can call on them as far as I’m aware? <a href="https://iosdev.space/tags/CoreData" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#CoreData</a>

Helge HeßSo, here we go, the adjusted RealmVsSwiftData test w/ a <a href="https://mastodon.social/tags/CoreData" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#CoreData</a> suite added. Took me longer than anticipated 🙂 Suggestions are welcome. CoreData seems to be roughly twice as fast as <a href="https://mastodon.social/tags/SwiftData" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#SwiftData</a>, but as expected still very slow. E.g. inserting 1m simple records takes ~1.15 *hours* (vs 2.75h in SwiftData, 6.5s in Realm and 8.2s in Lighter). The SwiftData test for updates (renames) still needs to be fixed, the original implementation is incorrect. <a href="https://github.com/Data-swift/RealmVsSwiftData/tree/feature/coredata-support" rel="nofollow noopener noreferrer" translate="no" target="_blank">https://github.com/Data-swift/RealmVsSwiftData/tree/feature/coredata-support</a>

Duncan BabbageA reason to argue against the observed object setup being the issue though is that separate tabs that have separately used @FetchRequest to obtain a list of entities, one of which is being handed down to these subviews, *do* correct update across tabs (close to) immediately when one is updated. So the changes are being received from the view context.So I guess I'm back to—why isn't my view context being updated correctly in <a href="https://iosdev.space/tags/SwiftUI" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#SwiftUI</a> when <a href="https://iosdev.space/tags/CoreData" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#CoreData</a> syncs in changes from iCloud? 🤔

Duncan BabbageWould love any leads on this: setting .fetchBatchSize causes entire collection to be immediately traversed <a href="https://developer.apple.com/forums/thread/756853" rel="nofollow noopener noreferrer" translate="no" target="_blank">https://developer.apple.com/forums/thread/756853</a> <a href="https://iosdev.space/tags/WWDC" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#WWDC</a> <a href="https://iosdev.space/tags/CoreData" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#CoreData</a>

Ramesh #NotGoingBackNew in <a href="https://mastodon.social/tags/SwiftData" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#SwiftData</a> this year: <a href="https://mastodon.social/tags/CustomDataStore" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#CustomDataStore</a>, going beyond the default <a href="https://mastodon.social/tags/CoreData" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#CoreData</a> store of last year to <a href="https://mastodon.social/tags/SQLite" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#SQLite</a>, <a href="https://mastodon.social/tags/RemoteWebService" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#RemoteWebService</a>, or even custom mapped <a href="https://mastodon.social/tags/JSON" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#JSON</a> files, with full support for <a href="https://mastodon.social/tags/historyTracking" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#historyTracking</a>

Keith SharpMy number one wish for <a href="https://hachyderm.io/tags/WWDC24" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#WWDC24</a> is to be able to configure <a href="https://hachyderm.io/tags/SwiftData" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#SwiftData</a> to turn off Write Ahead Logging, something like:let config = ModelConfiguration(url: storeURL, walEnabled: false) let container = try ModelContainer(for: Item.self, configurations: config)which would be the same as <a href="https://hachyderm.io/tags/coredata" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#coredata</a> let description = NSPersistentStoreDescription(url: storeURL) description.setValue("DELETE" as NSObject, forPragmaNamed: "journal_mode") container.persistentStoreDescriptions = [description]

Keith Harrison :clubtwit:Silencing the Core Data CloudKit sync debug messages that fill the Xcode console <a href="https://twit.social/tags/iOSDev" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#iOSDev</a> <a href="https://twit.social/tags/CoreData" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#CoreData</a> <a href="https://twit.social/tags/SwiftData" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#SwiftData</a> <a href="https://useyourloaf.com/blog/disabling-core-data-cloudkit-logging/" rel="nofollow noopener noreferrer" translate="no" target="_blank">https://useyourloaf.com/blog/disabling-core-data-cloudkit-logging/</a>

Axel Le PennecWith a <a href="https://iosdev.space/tags/SwiftUI" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#SwiftUI</a> SectionedFetchRequest, is there a performance difference between using a stored attribute vs a computed variable marked as objc?My thinking is that the stored attribute uses a GROUP BY SQL statement whereas the computed loads all objects in memory? Is that correct <a href="https://xoxo.zone/@numist" class="u-url mention" rel="nofollow noopener noreferrer" target="_blank">@numist</a>?<a href="https://iosdev.space/tags/CoreData" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#CoreData</a> <a href="https://iosdev.space/tags/iOSDev" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#iOSDev</a> <a href="https://iosdev.space/tags/iOS" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#iOS</a>

Axel Le PennecGiven a key path to an attribute on my model and a predicate to filter the elements, the @ FetchRequest/Query property wrappers should be able to return the sum/median/average/min/max/etc. whenever the underlying data changes (insert/update/delete) this refresh the <a href="https://iosdev.space/tags/SwiftUI" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#SwiftUI</a> View.<a href="https://iosdev.space/tags/SwiftData" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#SwiftData</a> <a href="https://iosdev.space/tags/CoreData" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#CoreData</a> <a href="https://iosdev.space/tags/iosdev" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#iosdev</a>

Axel Le PennecI really hope we'll be able to use function expressions in FetchRequest/Query/NSFetchedResultsController.I often use sum/average/min/max on my data using <a href="https://iosdev.space/tags/CoreData" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#CoreData</a> notifications to dynamically re calculate the values based on store changes. We need a built-in way!<a href="https://iosdev.space/tags/SwiftData" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#SwiftData</a> <a href="https://iosdev.space/tags/SwiftUI" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#SwiftUI</a>

Roman LefebvreChecking my crashlogs in the run up to <a href="https://indieapps.space/@sequel" class="u-url mention" rel="nofollow noopener noreferrer" target="_blank">@sequel</a> 2.1 release. You know, to make sure there's nothing worrying in there. Well, someone in the Core Data team sure killed my optimism 😂<a href="https://mastodon.design/tags/CoreData" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#CoreData</a>

Helge HeßI think a key flaw of both <a href="https://mastodon.social/tags/SwiftData" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#SwiftData</a> and <a href="https://mastodon.social/tags/CoreData" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#CoreData</a> is that they impose their own proprietary SQL schema. If it‘d worked on top of the plain SQL catalog (and EOF did), you could use it for more complex editing scenarios but still hit the DB w/ Lighter or GRDB for other things.

BillySangsterSpent the last week or so migrating a fairly sizeable project using CoreData to SwiftData. Kinda partially moved away from MVVM architecture as well. A few headaches along the way and quite a few things left to iron out, but happy with it on the whole.<a href="https://mastodon.scot/tags/iOS17" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#iOS17</a> <a href="https://mastodon.scot/tags/SwiftData" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#SwiftData</a> <a href="https://mastodon.scot/tags/CoreData" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#CoreData</a> <a href="https://mastodon.scot/tags/Apple" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#Apple</a> <a href="https://mastodon.scot/tags/SwiftUI" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#SwiftUI</a> <a href="https://mastodon.scot/tags/Swift" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#Swift</a>

kkla320Some thing that I really dislike about <a href="https://troet.cafe/tags/SwiftUI" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#SwiftUI</a> is the provided build in integration with <a href="https://troet.cafe/tags/CoreData" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#CoreData</a> or <a href="https://troet.cafe/tags/SwiftData" class="mention hashtag" rel="nofollow noopener noreferrer" target="_blank">#SwiftData</a>. The coupling of persistence and UI is a violation of separation of concerns. When you want to change your persistence you need to change your UI.

Recent searches

Search options

Administered by:

Server stats:

#coredata