-
Notifications
You must be signed in to change notification settings - Fork 156
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
PUT/PATCH don't support mongoose update operations #224
Comments
TIL: I honestly was not aware of this method! Could you post a PR to run our tests? |
welp this is a late reply. I haven't had the chance to put that PR up. my patchwork broke a lot of tests since it changes part of the core functionality and I don't have the time atm to look into it. It was more a proof of concept to see how hard/easy would it be to get the functionality So far I'm working around it by pushing to the list on the client side and sending the new list, but yeah it's not ideal |
By using While i agree that using |
If you decide to change this, please give consideration to the different semantics of PUT and PATCH. PUT is meant to replace a whole document. PATCH on the other hand is meant for just this use case. There is a very good reason to separate PUT from PATCH. PUT is idempotent, which means that a client can assume that applying a PUT operation twice will give the same result as applying it once. So, while $addToSet happens to be idempotent, operations like $push are not. |
Curious if there are any thoughts on what the query/body will look like for nested array updates -- would it adhere to Mongoose operators or something like RFC6902. |
Any update on this? |
This is by no means a complete solution (doesn't handle access-protected routes or routes filtered by any other criteria), but here's what I'm using right now to solve this problem locally:
This function just takes the request body and passes it directly to Currently, I mount this function at
To incorporate this type of solution (passing request body to
What do you all think about this? There's also the option of |
I'm not too fond of adding deep endpoints, I think it should be left to the user to create routes that go beyond That said, I do agree that having a way to use operators such as |
That's a good point about deep endpoints. For me, the key feature in opening up all of the MongoDB update operators is actually field deletion, because it's not currently possible to remove a field from a document. To perform PUT/PATCH ops, we're using
If we update PUT to completely replace the document, we would at least get field deletion via PUT, but we still won't have deletion via PATCH (which will still need to use |
This should work:
but because we use document.set instead of document.update we loose the ability to use any of the mongodb update operators
currently the way that request is handled it results in doing the following operation:
doc.save({'$addToSet.friends': 'BoB'})
instead of the desired:
doc.update({'$addToSet': {'friends': 'BoB}})
What do you think of this proposed solution? not tested yet, but seems to work on my use-cases
The text was updated successfully, but these errors were encountered: