Can I move an object in find to another?

[SettingDust]

Example:

{
    "array": [
        {
            "type": "__ID__",
            "value": [
                {
                    "type": "string",
                    "value": "123"
                },
                {
                    "type": "int",
                    "value": 1
                }
            ]
        }
    ]
}

Can I move the array.X.value to array when find the array.X.type matching?

{
    "array": [
        {
            "type": "string",
            "value": "123"
        },
        {
            "type": "int",
            "value": 1
        }
    ]
}

[EnderTurret]

I believe this is currently impossible, since find patches operate relative to each element and there is no way to traverse 'upward' from there. In other words, there's currently no way to raise { "type": "string", "value": "123" } into its parent array.

The reason for this is twofold. First, there's nothing in the JSON Path specification for relative versus absolute paths — all paths are assumed absolute (so technically find is slightly misusing the spec). Second, while patches can traverse child elements, they cannot traverse parents; no JSON library I know of represents JSON documents as a doubly-linked tree, and Gson certainly doesn't.

Sometime in the future I'd like to make this kind of thing possible, since it's one of the few current limitations of Patched (both the mod and the library). However, it's almost certainly going to require a spec violation. My current plans are to make beginning a path with ^ legal, which forces it to be an absolute path (and thus resolved from the root element). (This would not be a breaking change since paths must currently be empty or begin with a /.) In the provided example this might look like:

// 'find' patch omitted for brevity
{
  "op": "move",
  "from": "/value", // move the 'value' element...
  "path": "^array/-" // ... and place it in the 'array' element
}

This would be a good start, but it isn't perfect — in particular, you couldn't do this:

// input file
{
  "input": {
    "test": {
      "type": "number"
      "value": 3
    }
  },
  // pretend this element was added by an 'add' patch
  "numbers": {}
}

// patched file
{
  "input": { ... },
  "numbers": {
    "test": 3
  }
}

// patch
{
  // copy all 'number'-typed values into the 'numbers' object, preserving names
  "op": "find",
  "test": {
    "path": "/type",
    "value": "number"
  },
  "then": {
    "op": "copy",
    "from": "/value",
    "path": "^numbers/<???>/value"
  }
}

In other words, you can't have a path in terms of the current element using its name or index. In this case, <???> would ideally be some kind of placeholder for the current element name. Introducing such a placeholder would be another spec break (but it could be localized to only absolute paths), and it should really support multiple such placeholders. A modified version of that patch might look like:

// patch (modified)
{
  // copy all 'number'-typed values into the 'numbers' object, preserving names
  "op": "find",
  "placeholder": "my object"
  "test": {
    "path": "/type",
    "value": "number"
  },
  "then": {
    "op": "copy",
    "from": "/value",
    "path": "^numbers/{my object}/value"
  }
}

If done this way, placeholders could be given explicit names so that they're easier to differentiate from each other. This would also let you have say, ^values/{outer object}/{inner object}/value etc. Additionally, future secretly-a-loop-in-disguise patch types (should they ever exist) could reuse this placeholder API. (Or even worse, a mod adds a reinterpret_as_placeholder custom test type that turns a string value into a named placeholder.)

[SettingDust]

My current plans are to make beginning a path with ^ legal, which forces it to be an absolute path

How about start with //?

[EnderTurret]

That's already legal, and identifies the following element:

{  // "/"
  "": 1  // "//"
}

[SettingDust]

For reference. I've worked on a project that using something like the json patch but in mongodb syntax.
https://github.com/EpicBanItemTeam/EpicBanItem/blob/gh-pages/docs/en/rules-for-querying-and-updating.md#operator-for-arrays

It's using $ and $[] for placeholder.

[Desymoo]

My current plans are to make beginning a path with ^ legal, which forces it to be an absolute path (and thus resolved from the root element). (This would not be a breaking change since paths must currently be empty or begin with a /.)

Just out of curiosity - might this allow accessing the root element via "path": "^" in the future?

It would be amazing if we could patch over entire files to work around hard conflicts, which I believe isn't possible currently (at least with "/", but maybe there's something I'm missing?)

[EnderTurret]

Just out of curiosity - might this allow accessing the root element via "path": "^" in the future?

Yes. (Indeed, in my half-finished implementation the syntax has already changed to "^/path/to/element" to allow targeting the root with "^".)

which I believe isn't possible currently

This is already possible just by using "" (in Patched mod versions that include Patched 1.3.0 — which are 1.1.0+1.18.2, 2.3.0+1.19.2, 3.2.0+1.20.1, and up), although not inside of find. See e.g. this test, this test, or this test.