Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

fix: [REGAPIC] Fix repeated fields handling for query parameters #989

Merged
merged 1 commit into from
May 12, 2022

Conversation

vam-google
Copy link
Contributor

@vam-google vam-google commented May 10, 2022

if a field is declared as repeated in proto then its getter's name is get<FieldName>List not get<FieldName> instead.

@vam-google vam-google requested review from a team as code owners May 10, 2022 21:10
@vam-google vam-google requested a review from blakeli0 May 10, 2022 21:11
@sonarqubecloud
Copy link

sonarqubecloud bot commented May 10, 2022

Kudos, SonarCloud Quality Gate passed!    Quality Gate passed

Bug A 0 Bugs
Vulnerability A 0 Vulnerabilities
Security Hotspot A 0 Security Hotspots
Code Smell A 1 Code Smell

90.9% 90.9% Coverage
0.0% 0.0% Duplication

@vam-google vam-google requested review from Neenu1995 and eaball35 and removed request for Neenu1995 May 11, 2022 17:26
@blakeli0
Copy link
Collaborator

if a field is declared as repeated in proto then its getter's name is get<FieldName>List not get<FieldName> instead.

Why do we want to change this? Looks cosmetic to me. If it is indeed required change, do we want to port this over to GRPC client as well, like here? Also in the same class, there is another similar logic as well.

@@ -907,7 +907,9 @@ private Expr createFieldsExtractorClassInstance(
for (int i = 0; i < descendantFields.length; i++) {
String currFieldName = descendantFields[i];
String bindingFieldMethodName =
String.format("get%s", JavaStyle.toUpperCamelCase(currFieldName));
(i < descendantFields.length - 1 || !httpBindingFieldName.isRepeated())
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Is it easier to read if we change it to httpBindingFieldName.isRepeated() && i == descendantFields.length - 1? Also is it a valid case that a repeated field appear in positions other than the last one? Or you are just trying to be defensive here?
If it is indeed a valid case, can you please add a test case for it as well?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I just keep i < descendantFields.length - 1 construct in the if statement to be consistent with the rest of similar statements in the same method (there are several of them in this method).

No, repeated field can't have "nested" fields because repeated field is a List. But most importantly httpBindingFieldName.isRepeated() always represents the characteristic of the last field in the . chain only. I.e. if we have field_one.field_two.field_three there will be only one binding object with name = "field_one.field_two.field_three" and isRepeated = false if field_three is a regular field and isRepeated = true if it is repeated. field_one and field_two are guaranteed to be non-primitive, non-repeated message fields (when the type of field_one has a field named field_two), otherwise it would be a broken API definition.

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

If it's not a valid case, can we simplify it to if (!httpBindingFieldName.isRepeated())?

@vam-google
Copy link
Contributor Author

@blakeli0 This is not cosmetic, this is required for the generated code to compile, as get<FieldName>List() getter is generted by protobuf for repeated fields and get<FieldName>() for scalar fields.

As for porting it to grpc code - maybe, but it is not in scope of this PR as I don't want to risk breaking grpc code while working on regapic part (it is going to be a big rollout and I would like keep regapic changes separate to simplify debugging and minimize risk of breaking what is already working).

@vam-google vam-google merged commit f7ceab9 into googleapis:main May 12, 2022
@blakeli0
Copy link
Collaborator

As for porting it to grpc code - maybe, but it is not in scope of this PR as I don't want to risk breaking grpc code while working on regapic part (it is going to be a big rollout and I would like keep regapic changes separate to simplify debugging and minimize risk of breaking what is already working).

That makes sense and I think it's OK not porting over too. Because on gRPC side, the request extractor is only used for routing headers and the field can not be repeated AFAIK.

However, this is another example that we have long similar logics in multiple places which we could benefit a lot if extracted to common utility methods.

suztomo pushed a commit that referenced this pull request Dec 16, 2022
if a field is declared as repeated in proto then its getter's name is `get<FieldName>List` not `get<FieldName>` instead.
suztomo pushed a commit that referenced this pull request Mar 21, 2023
🤖 I have created a release *beep* *boop*
---


### Updating meta-information for bleeding-edge SNAPSHOT release.

---
This PR was generated with [Release Please](https://togithub.com/googleapis/release-please). See [documentation](https://togithub.com/googleapis/release-please#release-please).
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants