Bug?: ...UpdateInputs replace entire entries when mutating nested objects (sub-documents)

Given an example document:

User = {
  _id: "bar",
  account: {
    email: foo@foo.com,
    createdAt: ....,

The generated graphQl schema lists:
updateOneUser(query: UserQueryInput, set: UserUpdateInput!): User
input UserUpdateInput {..., account: UserAccountUpdateInput, .... }

According to documentation at: https://docs.mongodb.com/realm/graphql/types-and-resolvers/#updateinput, with UpdateInputs (so also UserAccountUpdateInput, I am assuming):

Any fields that you do not specify remain unchanged

Yet, executing the below mutation will completely replace the “account” sub-document, and not just update the specified field. Bug?

mutation {
  updateOneUser(query: {
  	_id: "bar"
  }, set: {account: {
    email: "bar@bar.com"
  }}) {...}

Hi Marc -can you explain a bit further on what you mean by “Is it possible to have both realm and stitch running on the same DB ?”

Are you referring to the SDKs here, or the backend app? In the case of the backend/cloud, Stitch/Realm are the same thing and you don’t really need to make changes to it. For the SDKs, while you can technically use both SDKs simultaneously while you migrate, we suggest making the changes all at once as shown here - https://docs.mongodb.com/realm/migrate/

Could anyone confirm if this is a bug or not? Maybe @Sumedha_Mehta1, since you are already taking part in the discussion? :wink:

Hey @_alex - it is intentional in the sense that we do not update singular fields in subdocuments today. I’m not sure if this is you, but it’s on our radar - Support for updating nested fields in GraphQL mutations – MongoDB Feedback Engine

Though not ideal, a custom resolver can also solve for having to update the entire subdocument for now.

Thank you for clarification, @Sumedha_Mehta1. And no, it is not me, who had added that ticket.

Could you provide an example of a reusable custom resolver? When I tried to create my own, I experienced some weird issues: GraphQl query with custom resolver for handling nested objects fails at random. Any idea on how to circumvent them?