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

Allow for custom types #427

Open
KaiserKarel opened this issue Jan 18, 2021 · 2 comments
Open

Allow for custom types #427

KaiserKarel opened this issue Jan 18, 2021 · 2 comments

Comments

@KaiserKarel
Copy link

KaiserKarel commented Jan 18, 2021

Packages such as https://github.com/envoyproxy/protoc-gen-validate allow for adding validation logic to protobuf messages. This works fine in Go, but Rust has a much more powerful type system, which can describe all required validation (https://lexi-lambda.github.io/blog/2019/11/05/parse-don-t-validate/).

It would be incredibly convenient if Prost would allow us to define these through custom options, where the author would pass the path of the rust type, which would implement TryFrom<T, Into<prost::DecodeError>> for the primitive type.

This would look something like this:

import "prost/prost.proto"

message Foo {
    string id = 1 [(prost.type).path = uuid::Uuid];
}

Instead of generating

pub struct Foo {
    pub id: String
}

We would generate:

pub struct Foo {
    pub id: uuid::Uuid
}

If uuid were to implement TryFrom<String, Into<prost::DecodeError>>.
Alternatively, we could implement prost::Message for a large number of types?

These options could then also allow for attributes per field defined inside the proto, e.g.

import "prost/prost.proto"

message Foo {
    string id = 1 [(prost.type).attr = #[serde(rename = "ID")]];
}
@sumeetattree
Copy link

I have a similar question: We have an interesting situation that I am having trouble with converting to grpc. The representation of undefined, null, and any value.

So, our graphql end point can accept a nullable field and it encodes it using this enum:

// async_graphql's representation
pub enum MaybeUndefined<T> {
    Undefined,
    Null,
    Value(T),
}

Internally, at the data-layer we can represent this object using Option<Option<T>> which is what diesel also works with, where
None => Undefined,
Some(None) => Null,
Some(Value) => any value.

From my limited understand of prost I don't see a way of translating MaybeUndefined into something that prost understands. Maybe I am missing something obvious here but is there a way to handle this with prost currently?

I am aware of these two issues: #303 and #276 , but I don't see them being directly applicable here due the generic nature of MaybeUndefined object.

Any help or direction would be greatly appreciated. If this is currently not possible with prost and if you'd be interested in a pr for this I would be more than happy to take it up @danburkert

@Victor-N-Suadicani
Copy link
Contributor

I had basically the same thought in #699. The fact that prost doesn't allow for any extra validation leads to a lot of duplication of types that are basically the same as the ones prost generated, but just validated in a better way.

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

No branches or pull requests

3 participants