-
Notifications
You must be signed in to change notification settings - Fork 533
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
Comments
I have a similar question: We have an interesting situation that I am having trouble with converting to grpc. The representation of 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 From my limited understand of prost I don't see a way of translating 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 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 |
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. |
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:
Instead of generating
We would generate:
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.
The text was updated successfully, but these errors were encountered: