gerlowskija commented on PR #2930: URL: https://github.com/apache/solr/pull/2930#issuecomment-2592944289
> Let's just do PATCH to /api/collections/myCollName to update anything updatable. We discussed PATCH a bit [here](https://github.com/apache/solr/pull/2930#discussion_r1915243956), and the slightly preferred option seemed to be to utilize PATCH only if we can find other APIs where it makes sense as well. Otherwise, it'd be the only place the HTTP method is used by Solr, and slightly unintuitive for that reason. I don't care strongly and am happy to flip-flop if other folks chime in for PATCH, but I think PUT has more support at the moment (I'm counting [epugh](https://github.com/apache/solr/pull/2930#discussion_r1907133948) and [hputman](https://docs.google.com/spreadsheets/d/1HAoBBFPpSiT8mJmgNZKkZAPwfCfPvlc08m5jz3fQBpA/edit?disco=AAAAbSSbh4A)). > to unset a value, why not just use null? As the PR exists today, with a POJO representing the request body, Jackson has no way to differentiate between fields that were absent from the request body entirely, and fields that were present with a null-value. In other words: if you're cramming them into a POJO at deserialization time, `{"foo": null}` and `{}` are indistinguishable on the server side. That said, I guess we don't strictly need a POJO. I _think_ we'd be able to distinguish these cases if we had Jackson deserialize into a Map instead. It'd make our OAS and codegen artifacts less specific (and therefore less useful) for this API, but maybe we're OK with that if it means avoiding the need for a `DELETE /api/collections/collName/metadata/replicationFactor`. If folks are OK dropping the request-body POJO, I can investigate going this route? -- 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: issues-unsubscr...@solr.apache.org For queries about this service, please contact Infrastructure at: us...@infra.apache.org --------------------------------------------------------------------- To unsubscribe, e-mail: issues-unsubscr...@solr.apache.org For additional commands, e-mail: issues-h...@solr.apache.org
