@rouuuge Thanks for the extra info.
I’ve recreated the issue and have raised the question with the engineering team. I’ll let you know when I get a response.
1 Like
Thank you @Andrew_Morgan!
I just checked the android SKD (java). There is the same problem as with the swift SDK.
Thanks for confirming. I suspect that the issue will be with the translator component in the backend that maps to Atlas documents
1 Like
Hi @rouuuge it appears that we’re running up against the differences between what’s supported by Objects and JSON Schema. Something to try (to allow you to modify documents in Atlas) is to click on the “Advanced Mode” button on the schema page in the Realm UI and set apply_when to false.
hi,
to allow you to modify documents in Atlas
my problem is not that i cant modify documents in Atlas. Or maybe I missunderstand you. This post I posted on february describe the problem maybe a bit more clearer:
hi @rouuuge,
The schema that you see in the Realm UI is used for a number of things – GraphQL API, Atlas document validations, and Realm Sync. I’m assuming that the part you care about is Realm Sync. My suggested workaround should stop the schema being used for Atlas document validation, and so (after the change) the schema shouldn’t prevent you from making changes to the Atlas data.
Could you share your iOS Object class definition plus the Realm schema? I’m travelling this week but I’ll try to reproduce the issue.
1 Like
Safe travels.
There you go, I replied to the original post
Hi @Georges_Jamous I’m afraid that I haven’t had chance to recreate this. Have you tried setting apply_when to false in the schema Advanced Mode?
hi @Andrew_Morgan
on Mar 18 you wrote:
I’ve recreated the issue and have raised the question with the engineering team. I’ll let you know when I get a response.
What was the response? It looks that you could recreated my example? If setting apply_when really the only solution could you describe bit more where to insert that rule? (btw im Using realm Sync)
thank you
I am not using GraphQL, just using iOS Sync. Where would I be able to change this?
I ran into the same issue today, do you have any update from the team?
I seems that the root cause is that no matter what the field type is, using a function to update it, it must have a value.
Non existent key, key set to null or key set to undefined does not work.
For my optional string schema, I had to pass an empty string ""
1 Like
I also attempted to update an existing object in the Database that was synced from iOS Client containing an non-existent value for an optional key.
In the Collection that value was Null.
await collection.updateOne(
{ _id: ... },
{ $set: { parentId: newID }},
{ session });
// the object I am updating here contains a key
// { name: null }
it failed stating the the value that was already non existent (NULL in record) needed to be Undefined. But it was Null. (again, the NULL value was set by the sync client form the SDK or Realm server)
Expected: undefined, given: null
it looks like the validation mechanism that runs when updating a value is different that the one during a sync operation in the backend
1 Like
hey @Georges_Jamous did you just found a solution? I also have a iOS-Sync App and run into the issue when i am using some serverside javascript functions.
@Sumedha_Mehta1 I had contact with you in April via mail. You suggest me this workaround:
Sounds like you’re asking for nullability support in our types. This is something we’re currently working on, but in the meantime I would suggest using the empty string, or some other dummy string because the InvalidTypeError is important for Sync.
Do you have maybe an update for this?
Luckily for me the key was obsolete, so I removed it to from the Schema.
Then there was no complaints from the API
But No, I did not find a solution.
From my tests, it seems that it is an issue in the Realm Backend Validation Service somewhere.
There is a clash between the Sync Client from mobile and the validation using the Functions.
The issue here is that null in MongoDB is treated as its own distinct type, which is quite different than how most developers would think about a nullable field in statically defined languages. A conversion feature/project is on deck for this quarter so hopefully we will get this sorted for you soon. In the meantime, you can use the workaround Sumedha described: define an empty value, or change the field to be required. Another option is leveraging our new Mixed type here:
Hope this helps
2 Likes
thx @Ian_Ward
as the deadline for the migration to mongodb is near: I guess the Workaround with empty / required is the best solution?
Yes, having the field required with an empty default value would always pass validation and prevent such errors. @rouuuge
Hi,
In relation to this thread, what would be the best recommended way to have a null value in an object relationship?
For instance, I have an object as follows:
public class Template : RealmObject
{
[PrimaryKey]
[MapTo("_id")]
public int TemplateId { get; set; }
public string TemplateDescription { get; set; }
public Department Department { get; set; }
public Example Example{ get; set; }
}
Where Department and Example are Realm objects.
When this is inserted into the realm by my .Net app, the entry in the MongoDB is as follows:
{
"_id":{"$numberLong":"123"},"
_partitionKey":"key",
"Example":null,
"Department":null,
"TemplateDescription":"Example"
}
This fails validation because of the null values of Department and Example even though it still syncs with the app.
How do you suggest I implement this as you can’t create a default Realm Object to use in a relationship?
Many Thanks