This won’t compile, but I need it to: class Foo: Object, ObjectKeyIdentifiable { @Persisted(primaryKey: true) var _id: ObjectId @Persisted var id: Int? @Persisted var name: String? }
The compile time error is: Invalid redeclaration of synthesized property ‘_id’
‘_id’ synthesized for property wrapper backing storage
Options? I’m using Realm Sync with Atlas, so _id is required to be there, plus I need “id” to exist because the relational backend code on that’s also talking to Atlas has defined that field for its use, and I can’t change it.
Should I not use the property wrapper and go back to @objc dynamic var and RealmProperty and so forth?
To clarify, are you saying your existing models have a _id property as well as a id property?
The issue with using @objc dynamic is that models can’t be mixed so you’ll need to revert any models which are using @Persisted properties to use @objc dynamic - is that an option? If so, for now, it’s probably the simplest solution.
You could also leverage a migration function in console to migrate all of the id fields to another property person_id for example and then update your models in code accordingly.
Thomas Goyne on the GitHub was kind enough to post a pretty good workaround for this problem.
If you are required to use both _id and id as properties in a Realm model class, like I do at this time, I found that this will work:
class IDObject: Object {
@objc dynamic var id: Int = 0
@objc dynamic var _id: ObjectId = ObjectId.generate()
override class func primaryKey() -> String? {
return "_id"
}
override class func shouldIncludeInDefaultSchema() -> Bool {
self != IDObject.self
}
}
class mymodel: IDObject, ObjectKeyIdentifiable {
@Persisted var name: String?
}
With this, the @objc dynamic vars in the base class will set up the primary key and the other id field without issue, and the extended class can use @persisted for everything else. Splitting it up like this allows @persisted to apply to everything other than _id and id…plus I have 20 other models with these exact same fields and configuration, so I may as well abstract that out anyway. the shouldIncludeInDefaultSchema() ensures that the IDObject base class doesn’t participate in the sync, and the auto discovery of all the other models still works fine.
Is that documented anywhere other than on the repo? :-/ …it seems like a reasonable workaround. We have a similar use case with an older app so I’ll give it a whirl.