You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The reason we have not immediately added it, is because we use custom structs to represent data, and do not use maps for resource types. So implementing PATCH for it made more sense at the time than converting it to a map and back to do this.
It's important to note that every user's data store varies, and while this feature may not be universally applicable, it could certainly benefit certain users.
@q-uint Thank you for the response. It makes sense.
Although the data store varies, I suppose, in most cases, the data model returned from the data store can be transformed into a map. At least, if theoretically there were a function that automatically applies a patch to a map, creating functions that convert data models to maps and back would be beneficial for the users of this package.
What's the current recommended approach to applying patches? Is it something like this?:
varentity*User// for each patch operationswitchop {
case"add":
addAttribute(entity, path, value)
case"remove":
removeAttribute(entity, path, value)
case"replace":
replaceAttribute(entity, path, value)
}
// where addAttribute, removeAttribute, and replaceAttribute know // how to apply a certain patch to a *User entity type
I was looking at how to implement data patching, and it appears that a working algorithm looks as follows:
map[string]interface{}
;If this is how the package is designed to work, it seems reasonable to implement a generic function that does data patching. Something like this:
Then, the handler will have a shape like this:
The text was updated successfully, but these errors were encountered: