feat(generator): add options support to generated clients #7683
Conversation
The generated client constructor now takes a defaulted `Options` argument, which is merged with the default options for the service, and then stored as a member. Similarly, the generated client operations also take a defaulted `Options` argument, which is then merged with the client options from above, and installed as the prevailing options for the duration of the operation by instantiating an `OptionsSpan`. Any module within the scope of that operation, or its continuations, can then retrieve those prevailing options. So, for example, a metadata decorator could add a header based on a per-operation option, or a retry policy might modify its behavior based on another option. This PR just changes the generator and its tests. Regeneration of the libraries will happen in a separate PR.
google-cla
bot
added
the
cla: yes
|
Google Cloud Build Logs
ℹ️ NOTE: Kokoro logs are linked from "Details" below. |
Codecov Report
@@ Coverage Diff @@
## main #7683 +/- ##
=======================================
Coverage 95.28% 95.29%
=======================================
Files 1254 1254
Lines 113503 113579 +76
=======================================
+ Hits 108155 108230 +75
- Misses 5348 5349 +1
Continue to review full report at Codecov.
|
|
Google Cloud Build Logs
ℹ️ NOTE: Kokoro logs are linked from "Details" below. |
|
Google Cloud Build Logs
ℹ️ NOTE: Kokoro logs are linked from "Details" below. |
|
Google Cloud Build Logs
ℹ️ NOTE: Kokoro logs are linked from "Details" below. |
| @@ -51,6 +51,9 @@ mapfile -t actual_dirs < <(env -C "${INSTALL_PREFIX}" find -type d) | |||
| mapfile -t expected_dirs < <(cat ci/etc/expected_install_directories) | |||
| expected_dirs+=( | |||
| ./include/google/api | |||
| ./include/google/bigtable | |||
There was a problem hiding this comment.
nit: this change seems unrelated, but I guess you had to do it as part of regenerating all the libraries?
There was a problem hiding this comment.
Correct. That is, apart from the generator changes themselves, everything else here was either generated or required by a test because of the regeneration.
| @@ -91,7 +91,7 @@ Status ClientGenerator::GenerateHeader() { | |||
| "$class_comment_block$\n" | |||
| "class $client_class_name$ {\n" | |||
| " public:\n" | |||
| " explicit $client_class_name$(std::shared_ptr<$connection_class_name$> connection);\n" | |||
| " explicit $client_class_name$(std::shared_ptr<$connection_class_name$> connection, Options options = {});\n" | |||
There was a problem hiding this comment.
I think using an unqualified Options here is Okay, because this code lives in google::cloud::$library$::v1_X_Y any Options class or struct (say one generated by protos) would be in google::cloud::$library$::v1 or some such namespace.
Is my reasoning correct?
There was a problem hiding this comment.
A little simpler that that, I think, in that I don't think we're expecting to find anything other than google::cloud::Options. We already do this for Options in existing library-qualified namespaces, and also for other "common" symbols.
The generated client constructor now takes a defaulted
Optionsargument,which is merged with the default options for the service, and then stored
as a member.
Similarly, the generated client operations also take a defaulted
Optionsargument, which is then merged with the client options from above, and
installed as the prevailing options for the duration of the operation by
instantiating an
OptionsSpan.Any module within the scope of that operation, or its continuations, can
then retrieve those prevailing options. So, for example, a metadata
decorator could add a header based on a per-operation option, or a retry
policy might modify its behavior based on another option.
This change is