Hello, thank you Apple for supporting custom store with SwiftData and the Schema type is superb to work with. I have successfully set one up with SQL and have some feedback and issues regarding its APIs.
- There’s a highlighted message in the documentation about not using internal restricted symbols directly, but they contradict with the given protocols and I am concerned about breaking any App Store rules. Are we allowed to use these? If not, they should be opened up as they’re useful.
- BackingData is required to set up custom snapshots, initialization, and getting/setting values. And I want to use it with
createBackingData()to directly initialize instances from snapshots when transferring them between server and client or concurrency. - RelationshipCollection for casting to-many relationships from backing data or checking if an array contains a PersistentModel.
- SchemaProperty for type erasure in a collection.
- BackingData is required to set up custom snapshots, initialization, and getting/setting values. And I want to use it with
- Schema.Relationship has KeyPath properties, but it is missing for Schema.Attribute and Schema.CompositeAttribute. Which means you can’t purely depend on the schema to map data. I am unable to access the properties of a custom struct type in a predicate unless I use Mirror with
schemaMetadata()or CustomStringConvertible on the KeyPath directly to extract it.- Trivial, but… the KeyPath property name is inconsistent (it’s all lowercase).
- It would be nice to retrieve property names from custom struct types, since you are unable access CodingKeys that are auto synthesized by Codable for structs. But I recently realized they’re a part Schema.CompositeAttribute, however I don’t know how to match these without the KeyPath…
- I currently map my entities using CodingKeys to their PredicateCodableKeyPathProviding.… but I wish for a simpler alternative!
- It’s unclear how to provide the schema to the snapshot before new models are created.
- I currently use a static property, but I want to make it flexible if more schemas and configurations are added later on.
- I considered saving and loading the schema in a temporary location, but doubtful that the KeyPath values will be available as they are not Codable.
- I suspect
schemaMetadata()has the information I need to map the backing data without a schema for snapshots, but as mentioned previously, properties are inaccessible…
- Allow access to entity metatypes, like value types from SchemaProperty. They’re useful for getting data out of snapshots and casting them to CodingKeys and PredicateCodableKeyPathProviding. They do not carry over when you provide them in the Schema.
- I am unable to retrieve the primary key from PersistentIdentifier.
- It seems like once you create one, you can’t get it out, like the DataStoreConfiguration in ModelContainer is not the one you used to set it up. I cannot cast it, it is an entirely different struct?
- I have to use JSONSerialization to extract it, but I want to get it directly since it is not a column in my database. It is transformed when it goes to/from my tables.
- It’s unknown how to support some schema options, such as Spotlight and CloudKit.
- Allow for extending macro options, such as adding options to set as primary key, whether to auto increment, etc…
- You can create a schema for super and sub entities, but it doesn’t appear you can actually set them up from the @Model macro or use inheritance on these models…
- SwiftData history tracking seems incomplete for HistoryDelete, because that protocol requires HistoryTombstone<Model>, but this type cannot be instantiated, nor does it contain anything useful to infer from.
- As an aside, I want to create my own custom ModelActor that is a global actor. However, I’m unable to replicate the executor that Apple provides where the executor has a ModelContext, because this type does not conform to Sendable. So how did Apple do this? The documentation doesn’t mention unchecked Sendable, but I figure if the protocol is available then we would be able to set up our own.
- And please add concurrency features!
Anyway, I hope for more continued support in the future and I am looking forward to what’s new this WWDC! 😊