Patch is deleting subdocument data

[imns]

My API uses feathers-mongoose for the db and when I send JSON (via postman) to patch my model I'm losing subdocument (embedded?) data. For example, if I have a model like this

social: {
        facebook: {
            url: String,
            likes: Number
        },
        twitter: {
            username: String,
            followers: Number
        }
}

and I send a patch request with

{
    "social": {
        "twitter": {
            "username": "@the_username"
        }
    }
}

it deletes social.facebook

Expected behavior

It shouldn't delete the sibling subdocuments. In this example social.facebook.

System configuration

Module versions (especially the part that's not working):
[email protected]

NodeJS version:
v6.5.0

[daffl]

Could this be the Mongoose/MongoDB default behaviour? It's just using Model.update (see https://github.com/feathersjs/feathers-mongoose/blob/master/src/service.js#L217).

[corymsmith]

You would have to use $set to only set that particular property in the subdocument

[corymsmith]

I think you want something like this.

usersService.patch(userId, { $set: { "social.twitter": {username: '@the_username'} } })

[imns]

I agree about using $set. This issue (feathersjs/feathers#323) mentions that $set is being used, but I don't see that anywhere.

@corymsmith I am not using feathers client. I'm sending a patch request directly to the API.

Update

I just tried sending { $set: { "social.twitter": {username: '@the_username'} } } with postman and it worked.

This seems counterintuitive since a patch request by nature needs to use $set.

Update2

$set seems to want dot notation. This works

"$set": { 
        "social.twitter.username": "@test"
    } 

[imns]

Also, I'm not sure about the API of other Database plugins, but doesn't using $set lock you into MongoDB instead of keeping the API DB agnostic?

[corymsmith]

When you send a patch of the following you are effectively saying, set only the social property to whatever I've passed in.

{
    "social": {
        "twitter": {
            "username": "@the_username"
        }
    }
}

The nature of patch is that it patches top level properties, otherwise how would the API know if you wanted to set a new value for social or if you wanted it to merge with the existing values unless you explicitly use $set? The other solution would be to first find the record, grab the social property, add the new twitter key and then issue a patch.

[corymsmith]

I'm not sure if it will work but you could also try a patch with this payload using dot notation:

{
    "social.twitter": {
            "username": "@the_username"
    }
}

[imns]

@corymsmith that second example does work without $set. That's also a good point about the patch behavior.

[corymsmith]

Perfect, I figured it would but didn't test it out before posting that comment :)

[daffl]

I think this has been figured out right? I think in general Feathers should leave the deep-merge behaviour up to the ORM since some (like all SQL ORMs) don't even support nested objects at all.

[imns]

Ya this is figured out.

[wvezey]

Yes, closed, and yet so helpful. Thank you all.

[FossPrime]

This is still a problem with AJV... { $set: { "social.twitter": {username: '@the_username'} } } would fail AJV unless you define an object key named "social.twitter", instead of "social" and then "twitter". My workaround is the obvious, overwrite and accept the consequences.