Also, in the guide all asynchronous calls are not handled correctly. eg anything like this
app.login(credentials: creds) { (user, error) in
No longer works after v10.0.0-rc.2 as they now appear to return a single result object
All Swift callbacks for asynchronous operations which can fail are now passed a Result<Value, Error> parameter instead of two separate Value? and Error? parameters.
So it looks like this
app.login(credentials: creds) { result in
Not sure why that change was made - it broke all of my error handling. Can we have an example of how that should be properly implemented?
IMO Result is too close to the existing Results object so it should have been named something else, but that’s me.
Edit: I believe the intended implementation is something like this?
switch result {
case .success(let realm):
//do something with realm
case .failure(let error):
print(error.localizedDescription)
}
Hey Jay, thanks for the comments. This guide is just for legacy Realm Sync users - non-sync users are not affected. The primary key _id field is only required for sync users, the docs are allowing ambiguity for non-sync users since there is no such requirement - we are working to split our docs right now to make it clear what is sync and what is non-sync. Stay tuned.
The Swift team did get a last minute change in for 10.0 that used Result in callbacks - this was to make our APIs more “swifty” since this is a pretty standard design pattern. Result is a builtin type and you don’t actually have to declare anything as a result. The Result/Results thing is pretty unfortunate, but I don’t really know what we can do about the standard library picking a name very similar to a name we were already using. We are updating the docs right now to use this new syntax and I’ve already updated the migration guide. Here is a code block for you in the meantime -
let email = "skroob@example.com"
let password = "12345"
app.login(credentials: Credentials.emailPassword(email: email, password: password)) { result in
DispatchQueue.main.async {
switch result {
case .success(let realm):
//do something with realm
case .failure(let error):
print(error.localizedDescription)
}
}
The newly introduced Realm App Interface is not found.
I’ve imported “Realms” namespace and Intellisense cannot resolve.
I’ve tried .Net 4.7.2 (my original project for Realm Cloud), .Net core and standard
The latest nuget package I found is Realm 5.1.2
I run into another error when building:
Error Could not copy the file “…\packages\Realm.10.0.0-beta.1\runtimes\win81-x64\native\realm-wrappers.dll” because it was not found.
Error Could not copy the file “…\packages\Realm.10.0.0-beta.1\runtimes\win81-x86\native\realm-wrappers.dll” because it was not found.
I’m on Win10 and VS Community 2019
the folders I have in the \packages\Realm.10.0.0-beta.1\runtimes are
win10*
win*
Are _partition properties automatically populated when adding new realm objects to realm ? Or do I need to do this manually on every object creation on the realm client ?
@timah You don’t have to set them in your client-side schema - it will be inferred from what you set-up as the partitionKey field on the server side and what value you open the realm with via the client-side API call. It should automatically inject this value when writing to Atlas. That being said, sometimes it helps to have the partitionKey be explicitly defined client side for readability.
@Jay That text is for the server-side MongoDB Atlas implementation, particularly as it pertains to initial sync. In MongoDB every document you want to sync must have a partitionKey and it must have a valid value, ie. a value that conforms to your configuration (so you couldn’t have a bool for partitionKey which you specified as string).
The question I was answering for @timah was regarding if the partitionKey field is required in the client side code, ie Swift Realm code, which it is not, because sync will automatically add that value and field to the document in MongoDB when it syncs.
@Ian_Ward. For whatever reason I was under the impression that a _partitionKey was a required property within Swift Realm Class models. Now that I re-read the documentation and the migration guide, the This field is critically important is only in relation to migrating from ROS to Mongo.
So, adding a partitionKey property in Swift Realm Objects is not required - the server will add that property (field) and value upon syncing as you mentioned.
Thanks. Yes, I know the docs very well by now. I’m just surprised that we don’t have some sort of “auto partition mode” where the _partition field is automatically filled with the ditto value requested by the SyncConfiguration.
@Jay The field used to be required, in the beta versions of the 10.0 SDKs, but with GA of 10.0 SDKs the field is now auto-pulled from the SyncConfiguration
Be sure to wipe your local state/simulator if you are making type changes like this. Then reconnect in developer mode. You may need to delete the old schema on the sync server side if you already saved it with the float unsupported type
