fix(bigtable): add materialized view routing param to ReadRows and Sa…

[mutianf]

…mpleRowKeys

ReadRows and SampleRowKeys can target a materialized view, but the client's request-params extractor only emitted table_name + app_profile_id and ignored materialized_view_name. Per the google.api.routing annotation in bigtable.proto, materialized views are instance-scoped and must route on the instance name.

Split the header composition into composeReadRequestParams (materialized-view capable) and composeWriteRequestParams (table/authorized-view only), and add NameUtil.extractInstanceNameFromMaterializedViewName.

Add HeadersTest coverage asserting the instance-name routing param for both operations, and a ReadIT integration test that reads through a materialized view.

[gemini-code-assist]

Code Review

This pull request adds support for routing read requests (ReadRows and SampleRowKeys) targeting materialized views in Cloud Bigtable. Since materialized views are instance-scoped, they route on the instance name instead of the table name. The changes introduce helper methods to extract the instance name, update the stub to handle this routing logic, and add corresponding tests. The feedback suggests omitting the app_profile_id parameter from the routing headers when it is empty to maintain consistency with write requests and avoid sending empty parameters to the server.

[mutianf]

/gemini review

[gemini-code-assist]

Code Review

This pull request introduces support for routing requests targeting materialized views in the Bigtable client. It updates EnhancedBigtableStub to extract instance-level routing parameters when a materialized view name is specified, and adds corresponding integration and header routing tests. The feedback suggests extracting the duplicated routing parameter extraction logic across the different callables in EnhancedBigtableStub into a single helper method to improve maintainability and code readability.

[gemini-code-assist]

The logic to extract routing parameters for read operations (which can target a table, authorized view, or materialized view) is duplicated across multiple callables. Consider extracting this into a helper method to improve maintainability and readability.

Here is an example of the helper method you can add to the class:

private Map<String, String> composeReadRequestParams(
    String appProfileId,
    String tableName,
    String authorizedViewName,
    String materializedViewName) {
  if (materializedViewName.isEmpty()) {
    return composeRequestParams(appProfileId, tableName, authorizedViewName);
  }
  return composeInstanceLevelRequestParams(
      MaterializedViewName.parse(materializedViewName).getInstanceName().toString(),
      appProfileId);
}

                        composeReadRequestParams(
                            r.getAppProfileId(),
                            r.getTableName(),
                            r.getAuthorizedViewName(),
                            r.getMaterializedViewName())

[gemini-code-assist]

This block duplicates the routing parameter extraction logic. Use the extracted composeReadRequestParams helper method here as well.

                        composeReadRequestParams(
                            r.getAppProfileId(),
                            r.getTableName(),
                            r.getAuthorizedViewName(),
                            r.getMaterializedViewName())

[gemini-code-assist]

This block duplicates the routing parameter extraction logic. Use the extracted composeReadRequestParams helper method here as well.

                            composeReadRequestParams(
                                r.getAppProfileId(),
                                r.getTableName(),
                                r.getAuthorizedViewName(),
                                r.getMaterializedViewName())