Conversation
The "V2 API" tabs for add-copy-field and delete-copy-field told users to POST a v1 keyed-object body to /api/collections/<coll>/schema. That path only carries GET, so the request is answered with a bodiless 405, and the body shape was wrong besides. Both now use the real v2 bulk endpoint and the operationType-discriminated list form. The one correct bulk example was not runnable as printed: each operation was missing the comma after "operationType", making the payload invalid JSON, and it posted to the v1 prefix /solr/<coll>/schema/bulk. That path does not resolve the JAX-RS resource; it falls through to the managed-resource handling under the v1 SchemaHandler and fails with "Expected Map to create a new ManagedResource but received a java.util.ArrayList". Also note that v2 names the copy-field target attribute destinations, with dest accepted as an alias, and state explicitly that /schema itself is GET-only in v2 so the bulk endpoint is discoverable.
|
Found this authoring a hands-on lab for our Solr training course. |
| { | ||
| "operationType":"add-copy-field", | ||
| "source":"shelf", | ||
| "destinations":[ "location", "catchall" ] |
There was a problem hiding this comment.
See #4943 for code work on the same. Need to decide between "destination" and "dest".
Also, if the destination fields require different maxChars settings, then you'll need to POST several requests, as the body JSON format here can only specify a global maxChars setting.
There was a problem hiding this comment.
json is so verbose already, so I don't mind destinations. Do we use dest or destinations in any other locations????
There was a problem hiding this comment.
V1 uses dest, and the GET endpoint listing all copyfield rules will return json objects with dest keys. Thus it would be nice if the request and response shapes use same keys.
Some of this may be thrown in the air by #4943 eventually, this PR is more to fix erraneous docs on the current main branch as it sits.
| "source":"shelf", | ||
| "destinations":[ "location", "catchall" ] | ||
| } | ||
| ]' http://localhost:8983/api/collections/techproducts/schema/bulk |
There was a problem hiding this comment.
oh, I think we changed this so that the url is at the beginning, not the end.
There was a problem hiding this comment.
These two will conflict, but let's handle conflicts during merge (whichever lands first), not try to align up front?
| "delete-copy-field":{ "source":"shelf", "dest":"location" } | ||
| }' http://localhost:8983/api/collections/techproducts/schema | ||
| curl -X POST -H 'Content-type:application/json' --data-binary '[ | ||
| { "operationType":"delete-copy-field", "source":"shelf", "destinations":[ "location" ] } |
There was a problem hiding this comment.
operationType? operation-type? I guess this is just documenting the existing actual implmeentaiton.
| [ | ||
| { | ||
| "operationType": "add-field" | ||
| "operationType": "add-field", |
There was a problem hiding this comment.
i wonder if this was valid under Noggit rules??? but yeah, lets fix it!
There was a problem hiding this comment.
Noggit won't complain even if you feed it a rat :) Which is bad, and we should not recommend broken JSON in our docs.
epugh
left a comment
There was a problem hiding this comment.
Some questsions, and a reference to another PR where we make all curl commands work the same, but other than that, this looks comittable.
Co-authored-by: Eric Pugh <epugh@opensourceconnections.com>
Description
Three "V2 API" examples in the Schema API ref guide don't work as printed. I hit this trying to edit schema fields over v2.
, which only carries@get, so it answers405withAllow:GET,OPTIONS
and an empty body — no hint that/schema/bulk` is one segment away."operationType"./solr/<coll>/schema/bulk, which doesn't resolve the JAX-RS resource; it falls through to managed-resource handling under the v1SchemaHandler:400 "Expected Map to create a new ManagedResource but received a java.util.ArrayList".Solution
Both copy-field tabs now use
POST /api/collections/<coll>/schema/bulkwith theoperationType-discriminated list form; the bulk example gets its commas and the/api/...prefix. Also documented that v2 names the attributedestinations— an alias, not a rename (@JsonAlias("dest"),deststill parses) — and that/schemais GET-only in v2, so the bulk endpoint is discoverable from the prose.Tests
Verified against a live Solr 10.0.0 SolrCloud node: reproduced both original failures, confirmed every path in the file now routes (reads
200, writes reachSchemaManager), and confirmed the corrected copy-field bodies parse and validate, including via thedestalias. Probes used invalid payloads and nonexistent field names, with zero schema residue afterwards. Every JSON payload in the file now parses except the two v1 examples with deliberately repeated keys, which noggit accepts by design.buildLocalAntoraSiteclean, no new warnings.Written with the assistance of Claude Code