Repository navigation
Indexed based array is too limited #12
Description
Given the documents:
{
"version": 0,
"roles": [
{ "name": "foo", "value": "bar" },
{ "name": "baz", "value": "foobar" },
{ "name": "fjsl", "value": "dowfo" }
]
}And:
{
"version": 1,
"roles": [
{ "name": "foo", "value": "bar" },
{ "name": "fjsl", "value": "dowfo" }
]
}I want to be able to write a patch:
{ "op": "remove", "path": "/roles/name", "value": "foobar" }This is useful when there is no guarantee that the array will always be in the same order, despite being guaranteed to have the same elements.
As JSON Patch currently works, I'm just going to re-factor my array into a hash. But it'd be nice to have this ability in the future.
Activity
grahamegrieve commentedon Jan 31, 2016
+1 for this. This restriction makes JSON Patch simple to implement, but also restricts it to very simple cases. A more sophisticated JSON patch that allowed you to specify a selection criteria for remove and replace (particularly) would allow JSON Patch to be used for a more robust set of use cases, but would significantly increase the complexity. Also, to my knowledge, there's no candidate query for json with a standards track?
heruan commentedon Nov 2, 2016
I agree,
removeoperation should permit to remove array elements without knowing the index. For example, given this JSON:{ "items": [ "a", "b", "c" ] }this patch should remove an item by value:
{ "op": "remove", "path": "/items/-", "value": "b" }to result in:
{ "items": [ "a", "c" ] }See #18.
konrad7d commentedon Feb 24, 2017
+1. The ability to update or remove an element based on its property or wider selection criteria could be very useful.
aalquist-akamai commentedon Mar 2, 2017
+1. this would make my logic more simple. For now, I'm using the test operator as a safety check.
HappyNomad commentedon Sep 8, 2017
While navigating to the removal location, you may need to traverse more than one collection from which you need to select an element based on its property's value. The syntax proposed by @jsumners won't work in this more general case, since it splits the selection criteria into
valueof which there's only one.Expressing each such traversal in the path as
property=valueis possible but unnecessarily complex.A simpler approach is to assume the identifying property's name and say that property's value where we'd otherwise say the element's index in the array. This involves eliminating array indices from the spec, or at least introducing an alternative "entity mode". Instead of array indices, we'd use the value of an element's "id" (not case-sensitive) property. For collections of scalar values, it would instead be the value itself.
So in @jsumners's simple example, the identifying property would be named "id" instead of "name". And the remove operation would be:
@heruan Your proposal only addresses collections of scalar values. What about collections of complex types as in @jsumners's example?
mitar commentedon Oct 12, 2019
As I wrote in this comment:
xanscale commentedon Feb 6, 2025
changing ARRAY to MAP<KEY, OBJECT> JSONPatch works by id and all works perfectly
jsumners commentedon Feb 6, 2025
...
Noted in the original post 10 years ago.
xanscale commentedon Feb 6, 2025
yes but it's quite hidden information.
personally i lost 2 hours before thinking to this solution, and when i'm ready to tell to the world, i found some little references in stackoverflow comments and here in the last row 😆
say5 commentedon Mar 31, 2025
Would be nice to have something like this:
remove: path/roles/-/name/foobarreplace: path/roles/-/name/foobarvalue:{SOMETHING}merge: path/roles/-/name/foobarvalue:{SOMETHING}(partial merge whereSOMETHINGoverrides matching keys).