-
Notifications
You must be signed in to change notification settings - Fork 129
Resource names across different protofiles #2711
Resource names across different protofiles #2711
Conversation
Codecov Report
@@ Coverage Diff @@
## master #2711 +/- ##
============================================
- Coverage 86.91% 86.83% -0.09%
+ Complexity 5623 5621 -2
============================================
Files 468 469 +1
Lines 22423 22467 +44
Branches 2440 2440
============================================
+ Hits 19490 19509 +19
- Misses 2082 2096 +14
- Partials 851 862 +11
Continue to review full report at Codecov.
|
Codecov Report
@@ Coverage Diff @@
## gapic_config_v2 #2711 +/- ##
==================================================
Coverage ? 86.94%
Complexity ? 5643
==================================================
Files ? 469
Lines ? 22474
Branches ? 2442
==================================================
Hits ? 19540
Misses ? 2083
Partials ? 851
Continue to review full report at Codecov.
|
# @param return_ [String] | ||
# @return [String] | ||
def self.return_path shelf, book, return_ | ||
RETURN_PATH_TEMPLATE.render( |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This RETURN_PATH_TEMPLATE comes from the pre-existing resource entity defined in another_service.proto, and now it shows up in the MyProtoClient generated class!
Note that there were no changes to the proto test files, only the gapic-generator sources.
|
||
DELETED_BOOK_PATH_TEMPLATE = Google::Gax::PathTemplate.new( | ||
"_deleted-book_" | ||
ARCHIVED_BOOK_PATH_TEMPLATE = Google::Gax::PathTemplate.new( |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is just re-ordering of the resource name artifacts. i thought it would make more sense to order them alphabetically, as it's deterministic and predictable.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
How were they ordered previously? Is this going to cause churn when we switch a client from v1 to v2 config?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Pretty sure it was ordered by the order in GAPIC interface's collections
, followed by any top-level non-duplicate API collections
So if there's no collections
field in the GAPIC config v2 to order the resource names, yeah we'll most likely get churn
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
OK. Not sure whether there is a coherent alternative, but I think that avoiding churn is a worthwhile goal. If it's not possible, we may just need to do a regeneration ahead of time to get the churn out of the way.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think we would have to do the regeneration pre-party, yeah. We could either draw ire now by changing the current generator to order resource name artifacts alphabetically (a billion changes at once for Yoshi), or API-by-API inside GAPIC configs (manual work on our part, but diffs are spread over time for Yoshi).
PTAL |
@michaelbausor any more comments? |
* Add Gapic config v2 (#2665) * Whittling down config_v2 (#2666) * Add ConfigV2 Validator (#2672) * AutoValue LongRunningConfig; always use gapic config's polling settings (#2698) * ResourceNameOneofConfig fixes (#2704) * Start parsing GAPIC config v2 (#2703) * Bring back timeout millis in GAPIC config v2 (#2708) * Resource names across different protofiles (#2711) * Fix missing default retries (#2718) * Bug fixes for gapic config v2 parsing (#2717)
* Add Gapic config v2 (googleapis#2665) * Whittling down config_v2 (googleapis#2666) * Add ConfigV2 Validator (googleapis#2672) * AutoValue LongRunningConfig; always use gapic config's polling settings (googleapis#2698) * ResourceNameOneofConfig fixes (googleapis#2704) * Start parsing GAPIC config v2 (googleapis#2703) * Bring back timeout millis in GAPIC config v2 (googleapis#2708) * Resource names across different protofiles (googleapis#2711) * Fix missing default retries (googleapis#2718) * Bug fixes for gapic config v2 parsing (googleapis#2717)
GAPIC config v1 has a way of limiting use of a resource entity to a particular interface, i.e.
service
in protobuf. API config spec can define a resource name in a protofile, though it cannot specify a particular service for the resource name.For all services in a protofile, generate the resource name artifacts that had resources defined in that protofile.
This is so APIs like Vision, which is composed of multiple protofiles, of which only some protos files have defined resource names, to only generate resource name utils in the classes where they are used. See the updated ruby baseline for an example.