gerlowskija commented on PR #2930: URL: https://github.com/apache/solr/pull/2930#issuecomment-2566985693
The biggest open question for this API (IMO) is how the "property unsetting" semantics should work for the v2 API. For context, the v1 API has "patch" semantics. That is - only the properties being modified need be provided. This is convenient and intuitive, but creates a problem that the v1 API felt it needed to solve: how can users "unset" a property entirely? In v1 this is done by providing a property, but with a value of empty-string (i.e. `""`). This is a problem in the v2 world, where properties are strongly typed. The v2 API expects properties like `perReplicaState` or `replicationFactor` to have non-string types (Boolean and Integer, respectively), so the empty-string flag value (understandably) triggers a Jackson deserialization error. I'm not totally sure what to do about this. We've got a few options, but I'm not sure what is best. 1. Ditch the strong-typing on our request-body POJO, so that the empty-string flag val is valid for all properties. 2. Investigate whether Jackson has some way to differentiate which properties were provided in the input JSON, and use that to support "unsetting". 3. Add an additional "unset" property to the request-body POJO, that takes a list of property names to unset in the collection-state. I've taken this approach for now in the PR to get tests, etc. passing - it was simple and easy to implement. But I don't like it as a long term solution. 4. Ditch support for property "unsetting" in v2 altogether. Others may know, but I'm not sure what use-case this capability serves. IMO it's confusing semantically - what does it mean to unset a "replicationFactor" property, for instance? It may be around for a very clear and relevant purpose, but if it's not, maybe removing it is a plausible path forward? 5. Something else? I'm a bit stumped on how to proceed, so I'd love feedback or thoughts if anyone has them. -- 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
