#coredata — Public Fediverse posts
Live and recent posts from across the Fediverse tagged #coredata, aggregated by home.social.
-
Hours wasted in figuring out another #SwiftUI #CoreData design flaw
Turns out after all these years, NSManagedObject does not implement ObservableObject's objectWillChange contract correctly.
FB24036828: NSManagedObject objectWillChange states it is emitted before the object changes when in reality it is emitted after it changes
-
Hours wasted in figuring out another #SwiftUI #CoreData design flaw
Turns out after all these years, NSManagedObject does not implement ObservableObject's objectWillChange contract correctly.
FB24036828: NSManagedObject objectWillChange states it is emitted before the object changes when in reality it is emitted after it changes
-
Hours wasted in figuring out another #SwiftUI #CoreData design flaw
Turns out after all these years, NSManagedObject does not implement ObservableObject's objectWillChange contract correctly.
FB24036828: NSManagedObject objectWillChange states it is emitted before the object changes when in reality it is emitted after it changes
-
Hours wasted in figuring out another #SwiftUI #CoreData design flaw
Turns out after all these years, NSManagedObject does not implement ObservableObject's objectWillChange contract correctly.
FB24036828: NSManagedObject objectWillChange states it is emitted before the object changes when in reality it is emitted after it changes
-
#buildInPublic #CoreData #swiftTesting
To satisfy myself that XCode doesn't touch the generated xxx+CoreDataClass.swift file if it exists, when regenerating the properties file, I made a small change and tried it. In the process I added the Swift testing file as a target, which made all my tests fail in strange ways.
back to regularly scheduled programming…
18/n
-
#buildInPublic #CoreData #swiftTesting
To satisfy myself that XCode doesn't touch the generated xxx+CoreDataClass.swift file if it exists, when regenerating the properties file, I made a small change and tried it. In the process I added the Swift testing file as a target, which made all my tests fail in strange ways.
back to regularly scheduled programming…
18/n
-
#buildInPublic #CoreData #swiftTesting
To satisfy myself that XCode doesn't touch the generated xxx+CoreDataClass.swift file if it exists, when regenerating the properties file, I made a small change and tried it. In the process I added the Swift testing file as a target, which made all my tests fail in strange ways.
back to regularly scheduled programming…
18/n
-
#buildInPublic #CoreData #swiftTesting
Since my inheritance tree for the DTOs maps 1:1 onto the CoreData managed objects, I'd like to inherit the class methods in the subclasses TDMTune and TDMTuneSet, e.g. in TDMTuneSet
class func makeInstance(from abcObj: AbcTuneSet, context: NSManagedObjectContext) -> TDMTuneSetUnfortunately Swift doesn’t allow overriding base-class methods in an extension, so I have to modify the generated TDMxxx+CoreDataClass.swift
17/n -
#buildInPublic #CoreData #swiftTesting
Since my inheritance tree for the DTOs maps 1:1 onto the CoreData managed objects, I'd like to inherit the class methods in the subclasses TDMTune and TDMTuneSet, e.g. in TDMTuneSet
class func makeInstance(from abcObj: AbcTuneSet, context: NSManagedObjectContext) -> TDMTuneSetUnfortunately Swift doesn’t allow overriding base-class methods in an extension, so I have to modify the generated TDMxxx+CoreDataClass.swift
17/n -
#buildInPublic #CoreData #swiftTesting
Since my inheritance tree for the DTOs maps 1:1 onto the CoreData managed objects, I'd like to inherit the class methods in the subclasses TDMTune and TDMTuneSet, e.g. in TDMTuneSet
class func makeInstance(from abcObj: AbcTuneSet, context: NSManagedObjectContext) -> TDMTuneSetUnfortunately Swift doesn’t allow overriding base-class methods in an extension, so I have to modify the generated TDMxxx+CoreDataClass.swift
17/n -
#buildInPublic #CoreData #swiftTesting
bit of a digression here: from my ObjC CoreData days I've been generating the NSManagedObject class definitions through XCode, then my own related code (in this case for translating back and forth from the DTOs) in a separate file as an objC category, with the generated files untouched.
I built class methods in the base TDMSearchable class
class func makeInstance(from abcObj : some AbcCollectable, context :NSManagedObjectContext) -> TDMSearchable
16/n -
#buildInPublic #CoreData #swiftTesting
bit of a digression here: from my ObjC CoreData days I've been generating the NSManagedObject class definitions through XCode, then my own related code (in this case for translating back and forth from the DTOs) in a separate file as an objC category, with the generated files untouched.
I built class methods in the base TDMSearchable class
class func makeInstance(from abcObj : some AbcCollectable, context :NSManagedObjectContext) -> TDMSearchable
16/n -
#buildInPublic #CoreData #swiftTesting
bit of a digression here: from my ObjC CoreData days I've been generating the NSManagedObject class definitions through XCode, then my own related code (in this case for translating back and forth from the DTOs) in a separate file as an objC category, with the generated files untouched.
I built class methods in the base TDMSearchable class
class func makeInstance(from abcObj : some AbcCollectable, context :NSManagedObjectContext) -> TDMSearchable
16/n -
-
-
-
#buildInPublic #CoreData #swiftTesting
next: Conversion of the DTOs to CoreData objects.
The current structure of JSON encoding assumes a top-down/denormalized structure for import, but since Tunes <-> TuneSets is many:many and Collectibles <-> Collections is m:m, I'd like a way to avoid re-specifying the containment tree.As part of that I'll need to look at how to de-duplicate with respect to existing objects.
14/n
-
#buildInPublic #CoreData #swiftTesting
next: Conversion of the DTOs to CoreData objects.
The current structure of JSON encoding assumes a top-down/denormalized structure for import, but since Tunes <-> TuneSets is many:many and Collectibles <-> Collections is m:m, I'd like a way to avoid re-specifying the containment tree.As part of that I'll need to look at how to de-duplicate with respect to existing objects.
14/n
-
#buildInPublic #CoreData #swiftTesting
next: Conversion of the DTOs to CoreData objects.
The current structure of JSON encoding assumes a top-down/denormalized structure for import, but since Tunes <-> TuneSets is many:many and Collectibles <-> Collections is m:m, I'd like a way to avoid re-specifying the containment tree.As part of that I'll need to look at how to de-duplicate with respect to existing objects.
14/n
-
#buildInPublic #CoreData #swiftTesting
ready to push to GitHub again. The DTOs are in the main project but only being exercised from the playground. Time to implement transferring from the DTO to the CoreData store.
(edit to put the GitHub link in)
https://github.com/Wil-Macaulay/attributedRelationships
13/n
-
#buildInPublic #CoreData #swiftTesting
ready to push to GitHub again. The DTOs are in the main project but only being exercised from the playground. Time to implement transferring from the DTO to the CoreData store.
(edit to put the GitHub link in)
https://github.com/Wil-Macaulay/attributedRelationships
13/n
-
#buildInPublic #CoreData #swiftTesting
ready to push to GitHub again. The DTOs are in the main project but only being exercised from the playground. Time to implement transferring from the DTO to the CoreData store.
(edit to put the GitHub link in)
https://github.com/Wil-Macaulay/attributedRelationships
13/n
-
#buildInPublic #CoreData #swiftTesting
I found a few similar ways of doing this using enum with associated type
https://medium.com/@ankuriosdev/mastering-advanced-json-decoding-in-swift-part-2-74d5a956dd0a
https://www.caseyliss.com/2023/2/2/decoding-heterogeneous-json-arrays-in-swift
This one from @paulio87 seems the most straightforward to me:
https://paul-samuels.com/blog/2019/01/02/swift-heterogeneous-codable-array/
it doesn’t require the domain DTOs (in this case AbcTune and AbcTuneSet) to have an explicit 'type’ field, but brings that out to a container.
(12/n)
-
#buildInPublic #CoreData #swiftTesting
I found a few similar ways of doing this using enum with associated type
https://medium.com/@ankuriosdev/mastering-advanced-json-decoding-in-swift-part-2-74d5a956dd0a
https://www.caseyliss.com/2023/2/2/decoding-heterogeneous-json-arrays-in-swift
This one from @paulio87 seems the most straightforward to me:
https://paul-samuels.com/blog/2019/01/02/swift-heterogeneous-codable-array/
it doesn’t require the domain DTOs (in this case AbcTune and AbcTuneSet) to have an explicit 'type’ field, but brings that out to a container.
(12/n)
-
#buildInPublic #CoreData #swiftTesting
I found a few similar ways of doing this using enum with associated type
https://medium.com/@ankuriosdev/mastering-advanced-json-decoding-in-swift-part-2-74d5a956dd0a
https://www.caseyliss.com/2023/2/2/decoding-heterogeneous-json-arrays-in-swift
This one from @paulio87 seems the most straightforward to me:
https://paul-samuels.com/blog/2019/01/02/swift-heterogeneous-codable-array/
it doesn’t require the domain DTOs (in this case AbcTune and AbcTuneSet) to have an explicit 'type’ field, but brings that out to a container.
(12/n)
-
#buildInPublic #CoreData #swiftTesting
(got distracted by other stuff, including wiring up a gazebo and playing tunes. Back at it now…)
I want to be able to allow the user to have an arbitrary Collection of Tunes and Sets in any order, so I’ll need an Array of Collectables [AbcCollectable]. Now I really am going to need to distinguish between a Tune and a TuneSet at runtime. (11/n)
-
#buildInPublic #CoreData #swiftTesting
(got distracted by other stuff, including wiring up a gazebo and playing tunes. Back at it now…)
I want to be able to allow the user to have an arbitrary Collection of Tunes and Sets in any order, so I’ll need an Array of Collectables [AbcCollectable]. Now I really am going to need to distinguish between a Tune and a TuneSet at runtime. (11/n)
-
#buildInPublic #CoreData #swiftTesting
(got distracted by other stuff, including wiring up a gazebo and playing tunes. Back at it now…)
I want to be able to allow the user to have an arbitrary Collection of Tunes and Sets in any order, so I’ll need an Array of Collectables [AbcCollectable]. Now I really am going to need to distinguish between a Tune and a TuneSet at runtime. (11/n)
-
#buildInPublic #CoreData #swiftTesting
I can't inherit CodingKeys, but I _can_ inherit init(from decoder) as well as superclass properties.
so I've implemented AbcCollectable as a superclass of AbcTune and AbcTuneSet, mirroring the TDMTune and TDMTuneSet relationships. (pushed to the GitHub repo for anyone who’s following along.
Next I want to implement AbcCollection as a container for _both_ AbcTunes and AbcTuneSets
(10/n)
-
#buildInPublic #CoreData #swiftTesting
I can't inherit CodingKeys, but I _can_ inherit init(from decoder) as well as superclass properties.
so I've implemented AbcCollectable as a superclass of AbcTune and AbcTuneSet, mirroring the TDMTune and TDMTuneSet relationships. (pushed to the GitHub repo for anyone who’s following along.
Next I want to implement AbcCollection as a container for _both_ AbcTunes and AbcTuneSets
(10/n)
-
#buildInPublic #CoreData #swiftTesting
I can't inherit CodingKeys, but I _can_ inherit init(from decoder) as well as superclass properties.
so I've implemented AbcCollectable as a superclass of AbcTune and AbcTuneSet, mirroring the TDMTune and TDMTuneSet relationships. (pushed to the GitHub repo for anyone who’s following along.
Next I want to implement AbcCollection as a container for _both_ AbcTunes and AbcTuneSets
(10/n)
-
#buildInPublic #CoreData #swiftTesting
Looks like I can't inherit CodingKeys from a superclass, I have to redefine them in any subclass that adds properties. Yet another example of the Swift language designers wagging their collective fingers at inheritance vs composition…
(9/n)
-
#buildInPublic #CoreData #swiftTesting
Looks like I can't inherit CodingKeys from a superclass, I have to redefine them in any subclass that adds properties. Yet another example of the Swift language designers wagging their collective fingers at inheritance vs composition…
(9/n)
-
#buildInPublic #CoreData #swiftTesting
Looks like I can't inherit CodingKeys from a superclass, I have to redefine them in any subclass that adds properties. Yet another example of the Swift language designers wagging their collective fingers at inheritance vs composition…
(9/n)
-
#buildInPublic #CoreData #swiftTesting
Do I need an explicit ‘type' field as shown here? let's see…
https://medium.com/@ankuriosdev/mastering-advanced-json-decoding-in-swift-part-2-74d5a956dd0a
(8/n)
-
#buildInPublic #CoreData #swiftTesting
Do I need an explicit ‘type' field as shown here? let's see…
https://medium.com/@ankuriosdev/mastering-advanced-json-decoding-in-swift-part-2-74d5a956dd0a
(8/n)
-
#buildInPublic #CoreData #swiftTesting
Do I need an explicit ‘type' field as shown here? let's see…
https://medium.com/@ankuriosdev/mastering-advanced-json-decoding-in-swift-part-2-74d5a956dd0a
(8/n)
-
#buildInPublic #CoreData #swiftTesting
A slight wrinkle: a Collection can contain both Tunes and TuneSets, in arbitrary order. In our CoreData model, we handle this by having a common superclass, Collectable, which has the common attributes and relationships. The ‘obvious' thing to do is have a common DTO superclass AbcCollectible handle basic encoding and decoding with the subclasses doing anything specific - in our trimmed down prototype that means TuneSet handling contained Tunes
(7/n) -
#buildInPublic #CoreData #swiftTesting
A slight wrinkle: a Collection can contain both Tunes and TuneSets, in arbitrary order. In our CoreData model, we handle this by having a common superclass, Collectable, which has the common attributes and relationships. The ‘obvious' thing to do is have a common DTO superclass AbcCollectible handle basic encoding and decoding with the subclasses doing anything specific - in our trimmed down prototype that means TuneSet handling contained Tunes
(7/n) -
#buildInPublic #CoreData #swiftTesting
A slight wrinkle: a Collection can contain both Tunes and TuneSets, in arbitrary order. In our CoreData model, we handle this by having a common superclass, Collectable, which has the common attributes and relationships. The ‘obvious' thing to do is have a common DTO superclass AbcCollectible handle basic encoding and decoding with the subclasses doing anything specific - in our trimmed down prototype that means TuneSet handling contained Tunes
(7/n) -
Moving from Core Data to SwiftData? Don't clean up your model on the first pass.
A practical "room by room" migration strategy showing why matching the legacy SQLite schema exactly is critical. Skip this and your users get a fatal error on launch.
🔗: https://emredegirmenci.substack.com/p/adopting-swiftdata-for-a-core-data by Emre Degirmenci (@aemre)
-
Moving from Core Data to SwiftData? Don't clean up your model on the first pass.
A practical "room by room" migration strategy showing why matching the legacy SQLite schema exactly is critical. Skip this and your users get a fatal error on launch.
🔗: https://emredegirmenci.substack.com/p/adopting-swiftdata-for-a-core-data by Emre Degirmenci (@aemre)
-
Moving from Core Data to SwiftData? Don't clean up your model on the first pass.
A practical "room by room" migration strategy showing why matching the legacy SQLite schema exactly is critical. Skip this and your users get a fatal error on launch.
🔗: https://emredegirmenci.substack.com/p/adopting-swiftdata-for-a-core-data by Emre Degirmenci (@aemre)
-
Moving from Core Data to SwiftData? Don't clean up your model on the first pass.
A practical "room by room" migration strategy showing why matching the legacy SQLite schema exactly is critical. Skip this and your users get a fatal error on launch.
🔗: https://emredegirmenci.substack.com/p/adopting-swiftdata-for-a-core-data by Emre Degirmenci (@aemre)
-
#buildInPublic #CoreData #swiftTesting
incidentally, nice summary of Codable with JSON here: https://medium.com/@ankuriosdev/basics-of-json-encoding-and-decoding-in-swift-language-6bb73affc6bb
(6/n)
-
#buildInPublic #CoreData #swiftTesting
incidentally, nice summary of Codable with JSON here: https://medium.com/@ankuriosdev/basics-of-json-encoding-and-decoding-in-swift-language-6bb73affc6bb
(6/n)
-
#buildInPublic #CoreData #swiftTesting
incidentally, nice summary of Codable with JSON here: https://medium.com/@ankuriosdev/basics-of-json-encoding-and-decoding-in-swift-language-6bb73affc6bb
(6/n)
-
#buildInPublic #CoreData #swiftTesting
Approach 1 would let us trivially use Decoders to ingest the data files and Encoders to write them, the files will get big fast.
Approach 2 lets us more easily manually prepare special test cases and is easier to understand. Let's go with approach 2.
(5/n) -
#buildInPublic #CoreData #swiftTesting
Approach 1 would let us trivially use Decoders to ingest the data files and Encoders to write them, the files will get big fast.
Approach 2 lets us more easily manually prepare special test cases and is easier to understand. Let's go with approach 2.
(5/n) -
#buildInPublic #CoreData #swiftTesting
Approach 1 would let us trivially use Decoders to ingest the data files and Encoders to write them, the files will get big fast.
Approach 2 lets us more easily manually prepare special test cases and is easier to understand. Let's go with approach 2.
(5/n) -
#buildInPublic #CoreData #swiftTesting
So we're introducing some Data Transfer Objects [DTOs] that can be trivially Codable.
How do we represent the [m:m] relationships? two choices:
1. denormalize in the json file, so that we start by ingesting Collections, providing a full copy of each TuneSet and Tune occuring in each Collection then culling out duplicates
2. introduce an ID attribute for each domain object so that we ingest relationships as an ID to be reconciled after ingestion.
(4/n) -
#buildInPublic #CoreData #swiftTesting
So we're introducing some Data Transfer Objects [DTOs] that can be trivially Codable.
How do we represent the [m:m] relationships? two choices:
1. denormalize in the json file, so that we start by ingesting Collections, providing a full copy of each TuneSet and Tune occuring in each Collection then culling out duplicates
2. introduce an ID attribute for each domain object so that we ingest relationships as an ID to be reconciled after ingestion.
(4/n) -
#buildInPublic #CoreData #swiftTesting
So we're introducing some Data Transfer Objects [DTOs] that can be trivially Codable.
How do we represent the [m:m] relationships? two choices:
1. denormalize in the json file, so that we start by ingesting Collections, providing a full copy of each TuneSet and Tune occuring in each Collection then culling out duplicates
2. introduce an ID attribute for each domain object so that we ingest relationships as an ID to be reconciled after ingestion.
(4/n) -
#buildInPublic #CoreData #swiftTesting
types (that is classes or structs) that are built from Codables can be trivially made codable. Fortunately most of the properties of our domain objects are Codable (Strings and Dates). however, NSManagedObjects are not directly Codable, since you need an NSManagedObjectContext to create an instance.
There are ways around that, but more importantly we've got [m:m] relationships in our data model which are hard to directly encode/decode. (3/n)
-
#buildInPublic #CoreData #swiftTesting
types (that is classes or structs) that are built from Codables can be trivially made codable. Fortunately most of the properties of our domain objects are Codable (Strings and Dates). however, NSManagedObjects are not directly Codable, since you need an NSManagedObjectContext to create an instance.
There are ways around that, but more importantly we've got [m:m] relationships in our data model which are hard to directly encode/decode. (3/n)
-
#buildInPublic #CoreData #swiftTesting
types (that is classes or structs) that are built from Codables can be trivially made codable. Fortunately most of the properties of our domain objects are Codable (Strings and Dates). however, NSManagedObjects are not directly Codable, since you need an NSManagedObjectContext to create an instance.
There are ways around that, but more importantly we've got [m:m] relationships in our data model which are hard to directly encode/decode. (3/n)