janhoy commented on PR #4177:
URL: https://github.com/apache/solr/pull/4177#issuecomment-5829409029
> I _think_ that atomic updates where work for me when I used the curl
commands in the ref guide.
Disclaimer: This comment is authored by Claude and reviewed by me
Good news on my original complaint: restoring content-type negotiation on
`/update` **fixes atomic updates over v2**. I probed the current branch against
`techproducts`:
| Request | Result |
|---|---|
| `POST /api/collections/c/update`, JSON **array** of atomic docs | ✅
applied atomically |
| `POST /api/collections/c/update`, single JSON **object** | ❌ `400 Unknown
command 'id'` |
| `POST /api/collections/c/update/json`, array **or** object | ⚠️ `200 OK`,
document **silently replaced** |
The third row is the dangerous one. `/update/json` maps to
`/update/json/docs`, so `{"id":"x","cat":{"add":"y"}}` is indexed as *literal
content* — the existing doc is overwritten and the other fields are lost. No
error, no warning. That's SOLR-11265, unchanged by this PR, but now reachable
through a v2 path we're actively documenting.
Two asks before merge:
1. `partial-document-updates.adoc` should say explicitly that atomic syntax
works on `/update` only, and that `/update/json` will silently destroy the
document.
2. Worth a follow-up JIRA to make `/update/json` **reject** atomic-operator
maps rather than index them.
The single-object-vs-array asymmetry on `/update` is also worth smoothing
over eventually — `{"id":...}` failing with `Unknown command 'id'` is a rough
first experience.
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
