You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Hi,
I'm trying to implement a request with optional (omit) parameters with validation constrains.
As far as I understand, optional field can be achieved using oneof.
In addition, protoc-gen-validate supports oneof.
Unfortunately, when using oneof, the swagger definition and grpc-ecosystem are changed and I can't use the original field name.
Whenever there is a oneof in the protobuf definition all the keys are simply added to the object: LastNameNull & LastNameValue. In other words, My request payload should contain LastNameValue instead of simply LastName.
Keep in mind that my Request struct fields should have the same naming as my DB struct for marshaling purposes, therefore the following will not work for me As it adds LastNameValue isUpdateRequest_LastNameValue to the generated struct:
If I try to send a request with FirstName defined, I get the following error json: cannot unmarshal string into Go value of type pb.isUpdateRequest_LastName.
According to @ivucica's comment I should implement UnmarshalJSONPB for that object. Unfortunately pb.isUpdateRequest_LastName is an interface and therefore his suggestion is not applicable.
What is your approach to unified DB & API validation errors?
I have 2 validation levels. gRPC request level (max length etc) and DB objects (email already exists, etc) which can result in different naming convention, especially when nested structs are involved.
I'm using the following interceptors to try and minimaize the situation by maintaining the same error structure.
But still, I'm using different structs and therefore there will be different Naming in the error message & field name.
Please advise how to handle this situation,
Thanks!
The text was updated successfully, but these errors were encountered:
Hi @johanbrandhorst ,
Thank for your input. I will definitely give it a try.
Update:
I'm no longer able to marshal the gRPC request struct into other structs such as DB objects: Which means that I need to start writing code for struct conversion.
I would say that the conversion of database validation errors into gRPC error is the responsibility of your gRPC server layer, not a gRPC interceptor. Whatever is returned from the gRPC server implementation should ideally already be a gRPC status. But this is the sort of thing that the #grpc channel on Gophers slack is great for discussing, so I'm going to close this issue.
Hi,
I'm trying to implement a request with optional (omit) parameters with validation constrains.
As far as I understand, optional field can be achieved using oneof.
In addition, protoc-gen-validate supports oneof.
Unfortunately, when using oneof, the swagger definition and grpc-ecosystem are changed and I can't use the original field name.
Given the following proto:
LastNameValue
instead of simplyLastName
.Keep in mind that my Request struct fields should have the same naming as my DB struct for marshaling purposes, therefore the following will not work for me As it adds
LastNameValue isUpdateRequest_LastNameValue
to the generated struct:If I try to send a request with
FirstName
defined, I get the following errorjson: cannot unmarshal string into Go value of type pb.isUpdateRequest_LastName
.According to @ivucica's comment I should implement UnmarshalJSONPB for that object. Unfortunately
pb.isUpdateRequest_LastName
is an interface and therefore his suggestion is not applicable.What is your approach to unified DB & API validation errors?
I have 2 validation levels. gRPC request level (max length etc) and DB objects (email already exists, etc) which can result in different naming convention, especially when nested structs are involved.
I'm using the following interceptors to try and minimaize the situation by maintaining the same error structure.
But still, I'm using different structs and therefore there will be different Naming in the error message & field name.
Please advise how to handle this situation,
Thanks!
The text was updated successfully, but these errors were encountered: