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

Add support for google.protobuf.Timestamp field #7195

Open
soham-suki opened this issue Sep 17, 2024 · 0 comments
Open

Add support for google.protobuf.Timestamp field #7195

soham-suki opened this issue Sep 17, 2024 · 0 comments
Assignees
Labels
type:feature_request feature request

Comments

@soham-suki
Copy link

soham-suki commented Sep 17, 2024

Describe the feature

It's a very common usecase to create go structs from proto, and directly use those structs as objects that gorm can scan into.
Similarly, it's also very common to use google.protobuf.Timestamp as a proto type to represent database timestamps. The problem is that gorm doesn't have an inbuilt serializer for this built-in type, which creates an error: invalid field found for struct User's field CreatedAt: define a valid foreign key for relations or implement the Valuer/Scanner interface.
Implementing the Valuer/Scanner interface isn't possible for this type, as you cannot define new methods on non-local types (the generated go code from the proto will live in a different package).
Additionally, using gorm serializers is not straightforward, since it requires generating protobuf implementations with gorm tags. This requires changing the way you build protobuf: by installing a new dependency (protoc-gen-gorm) and using it to create gorm tags. This isn't possible in our case as I'm hesitant on asking everyone in my company to install this dependency when they build protobuf.

Motivation

As pb.timestamp is a very common type, gorm should support serializing and deserializing to it out of the box.

Related Issues

#4604

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
type:feature_request feature request
Projects
None yet
Development

No branches or pull requests

2 participants