Add custom classes to represent Google Well Known Types

[hectorcast-db]

What changes are proposed in this pull request?

Add custom classes to represent Google Well Known Types

These classes have custom serialization:
https://protobuf.dev/reference/protobuf/google.protobuf/

How is this tested?

Added unit tests.

NO_CHANGELOG=true

[parthban-db]

LGTM!

[renaudhartert-db]

Should we use the Proto classes for internal (de)serialization with the protojson package?

[hectorcast-db]

Should we use the Proto classes for internal (de)serialization with the protojson package?

We specifically cannot use Proto FieldMask because it encapsulates the descriptor of the message, and validates the content.

var messageType *descriptorpb.DescriptorProto
fm, err := fieldmaskpb.New(messageType, "field.name", "field.number")

Except for that one, we could use the others. But this way we are slightly more consistent.
We also still have the original implementation of custom types for Python which copies the native types, and so we would need to change that again.

[parthban-db]

We specifically cannot use Proto FieldMask because it encapsulates the descriptor of the message, and validates the content.

I think we can use protoLibrary for marshalling/unmarshalling the fieldMask. However, we can't use the standard function to create it, as it needs a proto message. Instead, we can manually set the Paths field in the fieldMask message.

[hectorcast-db]

I think we can use protoLibrary for marshalling/unmarshalling the fieldMask. However, we can't use the standard function to create it, as it needs a proto message. Instead, we can manually set the Paths field in the fieldMask message.

Mmm... We can do that with the others. Like,

type Time struct {
 time.Time
}

func (t Time) Marshall() ([]byte, error) {
  pbTime := timepb.New(t.Time)
  return proto.Marshall(pbTime)
}

Thoughts?

[parthban-db]

Mmm... We can do that with the others. Like,
type Time struct {
time.Time
}
func (t Time) Marshall() ([]byte, error) {
pbTime := timepb.New(t.Time)
return proto.Marshall(pbTime)
}
Thoughts?

Looks good, but why are we storing this as time.Time and not timepb.Time?

[hectorcast-db]

Looks good, but why are we storing this as time.Time and not timepb.Time?

We are exposing this to the customer. I guess is a matter of preference on what we want the user to see:

type Time struct {
  time.Time //exposes go time 
}

type Time struct {
  timepb.Time // exposes pb time
}

type Time struct {
  internal <either> //exposes nothing
}

In python we did our own classes which "mimic" the python native time. So exposing native time, while not the same, seems slightly more consistent and requires less rework. Right now:

class Timestamp:
   def __init__(self, seconds: int = 0, nanos: int = 0) -> None:
     self.seconds = seconds
     self.nanos = nanos

We can change it again, but python this was already done, reviews, tested and ready to go.

[rauchy]

Suggested change

	return fmt.Errorf("json.Unmarshal on nil pointer")
	return fmt.Errorf("FieldMask.UnmarshalJSON on nil pointer")

[rauchy]

Suggested change

	// customDur := durationpb.New(30 * time.Second)
	// customDur := duration.New(30 * time.Second)

[github-actions]

If integration tests don't run automatically, an authorized user can run them manually by following the instructions below:

Trigger:
go/deco-tests-run/sdk-go

Inputs:

• PR number: 1271
• Commit SHA: 38b4cb979094db4eca55e60c8ffb07a8a4da6112

Checks will be approved automatically on success.

Discussed with the team and already applied the relevant changes.