Open maridonkers opened 1 year ago
This is a fair point, but how do you suggest this code to be generated instead?
This is a fair point, but how do you suggest this code to be generated instead?
Leading should be — if possible and feasible — that the generated code compiles? BTW: the OpenAPI generator produces Haskell client code with the exact same problem in the generated code...
The (manual) change to the generated for the above compilation error is trivial, so it's not a big problem anyway.
I do not know if it is still relevant but if you do not need the AggTrade
type you can use --opaque-schema="aggTrade"
to exclude it from generation (or rather let it generate as Aeson.Value
).
As far as I can see there are two solutions to this problem:
Any thought?
I do not know if it is still relevant but if you do not need the
AggTrade
type you can use--opaque-schema="aggTrade"
to exclude it from generation (or rather let it generate asAeson.Value
).
Thanks for the followup; with different options there was only one trivial change required to the generated code. I'm not yet sure if the AggTrade
is useful, but it may be. If not then the --opaque-schema
is indeed useful.
As far as I can see there are two solutions to this problem:
- Do less "smart" naming, especially do not uppercase different parts of the property name. The main disadvantage here is that is leads to quite unreadable names all throughout the generated code.
- Do some deduplication of (property) names. Ideally this should happen on global level but maybe doing it on a per-record-basis would be a first step as well.
Any thought?
My 2 cents would be the deduplication but is it worth the effort? (not sure how common the problem is irl)
For binance-api-swagger/spot_api.yaml the section
results in compilation error for generated files, as follows:
(the problem apparently originates in the "m" and "M", for which case is not handled)
Generated Haskell code section: