-
Notifications
You must be signed in to change notification settings - Fork 9
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
Add endpoints for add/replace/delete metadata #46
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
A ton of missing semicolon
and Do not access Object.prototype method 'hasOwnProperty' from target object
warnings. For the latter, you can always just attempt to access the property directly, and then evaluate the truthiness of the value to see if it exists or not; don't need to invoke the hasOwnProperty method at all.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
looks good. Good that you did the controller and service as well for these!
i guess it would be better to add the tag related routes in another PR. And those controllers will work a bit differently.
not sure what we decided about the existing POST /object/:objId (to update an object) and whether you were able to modify metadata there as well. I think we discussed this: https://discord.com/channels/689896523848613952/689896524406194236/991494695609974855 probably could go in a separate PR. I think we should merge this soon.. unit tests could go in a separate PR.
This should be moved to the validation layer eventially
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think we may need to consider the deleteMetadata behavior some more. Current proposed implementation has it so that you must explicitly ask for each key to be deleted before it will be dropped. I see situations where it is possible the user would like to drop ALL metadata keys from an object but do not want to go back and explicitly figure out what was there. I think we should be able to support this use case - in which case, instead of returning a 422, its possible that by NOT specifying anything, we assume all metadata is to be dropped outside of our enforced values.
Let's chat a bit about some of the subtle edge cases offline but in general, it's looking pretty good otherwise. 👍
Description
Adds new endpoints to add, replace, or delete metadata from an object. Each call will create a copy (and thus new version) of the object with the changes applied.
Types of changes
New feature (non-breaking change which adds functionality)
Checklist
Further comments