[
https://issues.apache.org/jira/browse/SOLR-18479?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=18118869#comment-18118869
]
Eric Pugh commented on SOLR-18479:
----------------------------------
Good news: I found the full story. Quick summary of the two PRs first, then
your new question.
PR #4203 — unrelated. That's SOLR-18152 (migrating the Schema Designer API to
JAX-RS), a different feature from the core Schema API this ticket is about.
PR #4901 (yours, merged 2026-09-21) — this is the relevant one, and it's
already in your local main. It migrated the Admin UI's Schema page to v2
endpoints, including copyField add/delete and field-type add/delete/replace. It
also fixed a real bug where UpdateSchema returned HTTP 200 with an error body
instead of a proper 4xx on failure.
But it does not close SOLR-18479 as filed. The ticket asks for dedicated v2
endpoints for copyField (e.g. something under /schema/copyfields), and that
still doesn't exist — UpdateSchemaApi.java still has the commented-out
addCopyField/deleteCopyField stub with the TODO explaining why (copyFields have
no single natural path-addressable name, being keyed by source + list of
destinations).
What the Admin UI does now for copyField (from schema.js in #4901):
$scope.addCopyField and $scope.deleteCopyField call
SchemaV2.bulkSchemaModification(...), sending a schemaChange array with
operationType: "add-copy-field" / "delete-copy-field" plus source/destinations.
That hits the existing generic catch-all POST
/api/\{cores|collections}/\{core}/schema/bulk endpoint — the same fallback path
the TODO comment calls out ("in the meantime, the functionality is exposed
through the bulk API at least"). Field-type add/replace uses the same
bulk-fallback pattern for replace-field-type (there's no dedicated replace
endpoint either), while plain add-field-type/delete-field-type do use their
dedicated endpoints.
So: the Admin UI is now v2-native end-to-end, but for copyField specifically
it's riding the generic bulk endpoint rather than a purpose-built one. If you
want SOLR-18479 marked resolved, you'd still need to design and add the
dedicated addCopyField/deleteCopyField API methods (deciding the URL/body shape
since there's no natural \{name}), then optionally switch the Admin UI over to
them. Want me to sketch that endpoint design, or is riding the bulk endpoint an
acceptable resolution to close the ticket as "won't fix as literally specified,
addressed via bulk"?
> Finalize V2 schema api for copyFields
> -------------------------------------
>
> Key: SOLR-18479
> URL: https://issues.apache.org/jira/browse/SOLR-18479
> Project: Solr
> Issue Type: Improvement
> Components: Schema and Analysis
> Reporter: Jan Høydahl
> Assignee: Jan Høydahl
> Priority: Major
>
> Currently, schema copyFields add/delete is not covered by JAX-RS style v2
> API, see
> [https://docs.google.com/spreadsheets/d/1HAoBBFPpSiT8mJmgNZKkZAPwfCfPvlc08m5jz3fQBpA/edit?pli=1&gid=605017626#gid=605017626]
> Add those in
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
