Use original Client's `client_info` in `_ensure_bqstorage_client` to create `BigQueryReadClient`

[b-schmeling]

Problem

If I set the user_agent in the client_info in a BigQueryClient, the resultant storage client from _ensure_bqstorage_client does not have the user agent I set.

This is visible in the code here:

def _ensure_bqstorage_client(
        self,
        bqstorage_client: Optional[
            "google.cloud.bigquery_storage.BigQueryReadClient"
        ] = None,
        client_options: Optional[google.api_core.client_options.ClientOptions] = None,
        client_info: Optional[
            "google.api_core.gapic_v1.client_info.ClientInfo"
        ] = DEFAULT_BQSTORAGE_CLIENT_INFO,
    ) -> Optional["google.cloud.bigquery_storage.BigQueryReadClient"]:
       ...

        if bqstorage_client is None:  # pragma: NO COVER
            bqstorage_client = bigquery_storage.BigQueryReadClient(
                credentials=self._credentials,
                client_options=client_options,
                client_info=client_info,  # type: ignore  # (None is also accepted)
            )

Solution

For _ensure_bqstorage_client to default to using the original client's client_info if no client_info is provided in the params.

The only part of the client_info that I really need in both clients is the user_agent, so alternatively I would be fully satisfied if just the user agent were propagated to the storage client.

Alternatives

For now, I believe I will have to manually create the bqstorage client with my own client_info.

Additional context

[tboddyspargo]

+1 This is one of several small barriers to simplifying our client creation process using the DBAPI. Today, we can't take advantage of the ability to automatically create the bqstorage_client, because it won't behave consistently with the original Client object's ClientInfo (and ClientOptions?).

[tboddyspargo]

Another possible solution would be to expose client_info (and client_options?) as arguments on dbapi.connect that get passed to the Connection constructor (and the _ensure_bqstorage_client invocation). While this wouldn't guarantee that the two clients behave consistently, it at least allows the caller to control the behavior of the bqstorage_client.

[tswast]

@tboddyspargo Could you describe more about your use case for client_options? One of the parameters on client options is the API endpoint. The API endpoints for BigQuery REST API and the BigQuery Storage API are different in the typical case.

[tboddyspargo]

@tboddyspargo Could you describe more about your use case for client_options? One of the parameters on client options is the API endpoint. The API endpoints for BigQuery REST API and the BigQuery Storage API are different in the typical case.

No use-case for that one. I just assumed it might also contain configuration that would apply to both clients and therefore be desirable to keep aligned.

[Linchin]

I am working on a solution for this

[parthea]

Transferring to google-cloud-python as the code for python-bigquery will be migrated there in 1-3 weeks.

[parthea]

Transferring this issue back to python-bigquery.