gerlowskija commented on pull request #218: URL: https://github.com/apache/solr/pull/218#issuecomment-968089083
> Do we actually need the captureConvertedV1Params and the mapping between V1 and V2 tests? Do we care that V2 is different then V1???? I think so, but maybe you can correct me. Here's the case I'd make for them: Right now our v2 APIs are mostly written as a thin interface that calls out to existing v1 functionality. e.g. `AddReplicaAPI` doesn't really have replica-adding logic - it just shuffles some parameters around and calls the v1 logic that already exists in `CollectionsHandler.handleRequestBody`. So to have confidence in our v2 API, we need to verify two things: 1. That `CollectionsHandler.handleRequestBody` works as expected. 2. That the "parameter shuffling" AddReplicaAPI does before calling `handleRequestBody` is correct. The first is already verified by many tests throughout the codebase. So that box is checked. We should already have lots of confidence in `/solr/admin/collections?action=ADDREPLICA`. That just leaves (2). To trust AddReplicaAPIs replica-property support, we need to verify that AddReplicaAPI's JSON map of properties gets flattened and prefixed with `property.`. To trust AddReplicaAPI's handling of nodeset values we need to verify that they are converted from the nice JSON list that AddReplicaAPI offers to the comma-delimited string that v1 requires. And so on. That's what the tests in this PR are doing. They're not ensuring that v1 and v2 are the same - they don't have to be. They're ensuring that when a v2 API makes use of v1 code, it's invoking that code correctly. -- 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
