oapi-codegen
oapi-codegen copied to clipboard
Create slice/map/string fields without pointers (for optional fields)
Default value for slice/map is nil
. So slice/map field will not be serialized if it is not initialized.
I mean from serialization point of view these two structs are the same:
struct {
GroupKey *[]string `json:"group_key,omitempty"`
}
struct {
GroupKey []string `json:"group_key,omitempty"`
}
The later version is more convenient to work with..
https://play.golang.org/p/0c0nVaoOPNK
Also the same applies to string
type with omitempty
json tag.
Pointer to interface *interface{}
struct fields are also useless.
That would be good.
Also the same applies to string type
Why it applies also to string?
@mitar https://play.golang.org/p/0c0nVaoOPNK here you can look at 33-42 lines for small example
Sure, but how would you know for strings if field has been provided and is empty string vs. it has not been provided at all?
It makes sense. Maybe then it is better to use x-go-type
extended property explicitly for your use case ? Nevertheless I suppose that most programmers almost always use simple string fields for structs (string field with omitempty
tag) and your use case is very data specific.
I mean, I completely agree that those pointers seem to be more or less unnecessary, in almost all cases. And pain to work with. But then I also hate when in grpc/protobuf I cannot know if value was provided or not for zero values. Maybe something like that would be even better:
struct {
GroupKey string `json:"group_key,omitempty"`
GroupKeyProvided bool `json:-`
}
It should be up to the application to decide whether a missing value is equivalent to a zero value. I'd like to propose a solution that works for both cases. The nullable
field should control indirection.
Option 1: Binary nullable (true, false)
This is my preference. Missing/false are treated identically. The default value for nullable
is false
per the OpenAPI 3 spec.
-
required && nullable
->Foo *string `json:"foo"`
-
required && !nullable
->Foo string `json:"foo"`
-
!required && nullable
->Foo *string `json:"foo,omitempty"`
-
!required && !nullable
->Foo string `json:"foo,omitempty"`
Option 2: Ternary nullable (true, false, missing)
Same as option 1, but when absent nullable
defaults to `!required (nullable if not required non-nullable if required). This maintains current default behavior as of this writing while still allowing explicit override.
I'm happy to contribute a change for either approach.
I think the first option is better as it is more intuitive to understand. @deepmap-marcinr what do you think ?
Binary nullable is a good option! But I'm sad what it's not implemented yet. Is there any updates since aug?
Is there any chance of merging the PR that is solving this issue?
Let's make this PR flaggable via the Configuration
structure, then it's good to go. Whenever we've made breaking changes, people complain, so let's be nice about it.
I've been away for a while, sorry for tardy responses.
Would be awesome, as e.g. https://github.com/uptrace/bun struggles with pointer slices