-
Notifications
You must be signed in to change notification settings - Fork 1.4k
feat(bigquery/storage/managedwriter/adapt): add NormalizeDescriptor #4681
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
Conversation
This functionality supports the "bring your own proto" case for writing data. Towards: googleapis#4366
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.
LGTM, but a few questions
var normalizationSkipList = []string{ | ||
".google.protobuf.DoubleValue", | ||
".google.protobuf.FloatValue", | ||
".google.protobuf.Int64Value", |
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.
Do we support well known types now? Or is this to make sure they're supported when the backend adds support?
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.
They're well known, so the backend shouldn't have issues resolving them without repacking. Getting them to behave as expected for the proto3 case is still the ongoing discussion. I could do some more integration testing on this front, but I wanted to get some other changes in to the main client before adding them.
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.
If these are skipped, what is happening? Maybe it is good to have a e2e test to show the behavior.
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.
Added integration testing, turns out the backend won't do the resolution:
integration_test.go:617: error in response: rpc error: code = InvalidArgument desc = Invalid proto schema: BqMessage.proto: testdata_WithWellKnownTypes.wrapped_int64: ".google.protobuf.Int64Value" is not defined.
BqMessage.proto: testdata_WithWellKnownTypes.wrapped_string: ".google.protobuf.StringValue" is not defined. Entity: projects/shollyman-demo-test/datasets/managedwriter_test_dataset_20210827_73498187205915_0001/tables/table_20210827_73498187245922_0002/_default
Yiru, you want a bug for this?
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 what you want is a direct support on wrappers, which we currently don't have. So it should be a dup to the same bug. Since Pavan suggested a way of not needing an annotation, we could make the decision based on the BQ table schema (which means I can fix it sooner). But again, such behavior needs to be consistent across client libs.
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 want direct support on wrappers, but that's tied up in the other proto3 topics. I did expect that the well known types would just work out of the box, even if the api treated them as record types with a single value field.
return nil, fmt.Errorf("error converting message %s: %v", inField.FullName(), err) | ||
} | ||
root.NestedType = append(root.NestedType, dp) | ||
visitedTypes.delete(msgFullName) |
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.
Why do we delete this? I guess because "visited" is more about detecting recursive types? I wonder if there's a more descriptive name we could use? (Ancestor types?)
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 chose the names to keep it aligned with the other implementations, but its definitely something I think we could consider. Currently the internal C++ impl is the baseline, so we'd want to start there.
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.
Fair enough. IMO the C++ impl could have better names, then. :-)
enumFullName := string(inField.Enum().FullName()) | ||
enclosingTypeName := normalizeName(enumFullName) + "_E" | ||
enumName := string(inField.Enum().Name()) | ||
actualFullName := fmt.Sprintf("%s.%s", enclosingTypeName, enumName) |
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.
Is it just enums that get the dots? Why is that? Oh, is it because we actually generated the enclosing struct so we know it's properly nested?
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.
Yeah, gets deep into enum internals.
From the proto guide:
You can also use an enum type declared in one message as the type of a field in a different message, using the syntax MessageType.EnumType.
It's basically ensuring the enums don't collide by being explicit about the struct wrapping.
Maybe the fix is to add the wrapper.proto as a known reference.
…On Fri, Aug 27, 2021 at 2:40 PM shollyman ***@***.***> wrote:
***@***.**** commented on this pull request.
------------------------------
In bigquery/storage/managedwriter/adapt/protoconversion.go
<#4681 (comment)>
:
> +
+func newStringSet() *stringSet {
+ return &stringSet{
+ m: make(map[string]struct{}),
+ }
+}
+
+func normalizeName(in string) string {
+ return strings.Replace(in, ".", "_", -1)
+}
+
+// these types don't get normalized into the fully-contained structure.
+var normalizationSkipList = []string{
+ ".google.protobuf.DoubleValue",
+ ".google.protobuf.FloatValue",
+ ".google.protobuf.Int64Value",
I want direct support on wrappers, but that's tied up in the other proto3
topics. I did expect that the well known types would just work out of the
box, even if the api treated them as record types with a single value field.
—
You are receiving this because your review was requested.
Reply to this email directly, view it on GitHub
<#4681 (comment)>,
or unsubscribe
<https://github.com/notifications/unsubscribe-auth/AHGYVESHSFX54QV7GMX2TIDT7AA5FANCNFSM5C4IKWUA>
.
Triage notifications on the go with GitHub Mobile for iOS
<https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675>
or Android
<https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub>.
--
Thanks.
Yiru
|
In that sense we can have a separate bug.
…On Fri, Aug 27, 2021 at 2:43 PM Yiru Tang ***@***.***> wrote:
Maybe the fix is to add the wrapper.proto as a known reference.
On Fri, Aug 27, 2021 at 2:40 PM shollyman ***@***.***>
wrote:
> ***@***.**** commented on this pull request.
> ------------------------------
>
> In bigquery/storage/managedwriter/adapt/protoconversion.go
> <#4681 (comment)>
> :
>
> > +
> +func newStringSet() *stringSet {
> + return &stringSet{
> + m: make(map[string]struct{}),
> + }
> +}
> +
> +func normalizeName(in string) string {
> + return strings.Replace(in, ".", "_", -1)
> +}
> +
> +// these types don't get normalized into the fully-contained structure.
> +var normalizationSkipList = []string{
> + ".google.protobuf.DoubleValue",
> + ".google.protobuf.FloatValue",
> + ".google.protobuf.Int64Value",
>
> I want direct support on wrappers, but that's tied up in the other proto3
> topics. I did expect that the well known types would just work out of the
> box, even if the api treated them as record types with a single value field.
>
> —
> You are receiving this because your review was requested.
> Reply to this email directly, view it on GitHub
> <#4681 (comment)>,
> or unsubscribe
> <https://github.com/notifications/unsubscribe-auth/AHGYVESHSFX54QV7GMX2TIDT7AA5FANCNFSM5C4IKWUA>
> .
> Triage notifications on the go with GitHub Mobile for iOS
> <https://apps.apple.com/app/apple-store/id1477376905?ct=notification-email&mt=8&pt=524675>
> or Android
> <https://play.google.com/store/apps/details?id=com.github.android&referrer=utm_campaign%3Dnotification-email%26utm_medium%3Demail%26utm_source%3Dgithub>.
>
>
--
Thanks.
Yiru
--
Thanks.
Yiru
|
This functionality supports the "bring your own proto" case for writing
data.
Differences from the java equivalent:
Towards: #4366