Skip to content

Fix incorrect v2 API examples in the Schema API ref guide - #4942

Open
janhoy wants to merge 2 commits into
apache:mainfrom
janhoy:fix-v2-schema-api-docs
Open

janhoy wants to merge 2 commits into
apache:mainfrom
janhoy:fix-v2-schema-api-docs

Conversation

@janhoy

@janhoy janhoy commented Sep 24, 2026 •

Copy link
Copy Markdown
Contributor

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.

  1. Both copy-field V2 tabs point at a GET-only endpoint. They POST a v1 keyed-object body to /api/collections/techproducts/schema, which only carries @get, so it answers 405withAllow:
    GET,OPTIONSand an empty body — no hint that/schema/bulk` is one segment away.
  2. The one correct bulk example is invalid JSON — missing comma after each "operationType".
  3. That same snippet uses the v1 prefix /solr/<coll>/schema/bulk, which doesn't resolve the JAX-RS resource; it falls through to managed-resource handling under the v1 SchemaHandler: 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/bulk with the operationType-discriminated list form; the bulk example gets its commas and the /api/... prefix. Also documented that v2 names the attribute destinations — an alias, not a rename (@JsonAlias("dest"), dest still parses) — and that /schema is 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 reach SchemaManager), and confirmed the corrected copy-field bodies parse and validate, including via the dest alias. 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. buildLocalAntoraSite clean, no new warnings.

Written with the assistance of Claude Code

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.
@janhoy
janhoy requested review from epugh and gerlowskija September 24, 2026 15:54
@github-actions github-actions Bot added the documentation Improvements or additions to documentation label Sep 24, 2026
@janhoy

janhoy commented Sep 24, 2026

Copy link
Copy Markdown
Contributor Author

Found this authoring a hands-on lab for our Solr training course.

@janhoy janhoy added this to the 9.x milestone Sep 24, 2026
{
"operationType":"add-copy-field",
"source":"shelf",
"destinations":[ "location", "catchall" ]

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

json is so verbose already, so I don't mind destinations. Do we use dest or destinations in any other locations????

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Comment thread solr/solr-ref-guide/modules/indexing-guide/pages/schema-api.adoc Outdated
"source":"shelf",
"destinations":[ "location", "catchall" ]
}
]' http://localhost:8983/api/collections/techproducts/schema/bulk

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

oh, I think we changed this so that the url is at the beginning, not the end.

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

#4925 is where this is proposed...

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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" ] }

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

operationType? operation-type? I guess this is just documenting the existing actual implmeentaiton.

[
{
"operationType": "add-field"
"operationType": "add-field",

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

i wonder if this was valid under Noggit rules??? but yeah, lets fix it!

Copy link
Copy Markdown
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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 epugh left a comment

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

documentation Improvements or additions to documentation no-changelog

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants