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

[bug][Kotlin] Default typeMapping for 'date' should be LocalDate #2063

Closed
5 tasks done
legzo opened this issue Feb 5, 2019 · 5 comments · Fixed by #2981
Closed
5 tasks done

[bug][Kotlin] Default typeMapping for 'date' should be LocalDate #2063

legzo opened this issue Feb 5, 2019 · 5 comments · Fixed by #2981

Comments

@legzo
Copy link

legzo commented Feb 5, 2019

Bug Report Checklist

  • Have you provided a full/minimal spec to reproduce the issue?
  • Have you validated the input using an OpenAPI validator (example)?
  • What's the version of OpenAPI Generator used?
  • Have you search for related issues/PRs?
  • What's the actual output vs expected output?
Description

When a spec specifies a property as :

"type": "string",
"format": "date",

the Kotlin generator generates the corresponding field as a LocalDateTime and later, the parsing fails when Jackson is used (Gson too) saying it cannot find a converter for this type.

As I understand the spec, "format":"date" should result in a LocalDate and "format":"date-time" in a LocalDateTime

openapi-generator version

I tried version 3.3.4, but I read the code of master and the problem is still present.

Steps to reproduce

Use as an input any spec that has a property configured as :

"type": "string",
"format": "date",
Suggest a fix/enhancement

I think there is only one line to change at

it should be

 typeMapping.put("Date", "java.time.LocalDate");

I can provide a PR if you think it is really a bug.

Cheers.

@auto-labeler
Copy link

auto-labeler bot commented Feb 5, 2019

👍 Thanks for opening this issue!
🏷 I have applied any labels matching special text in your issue.

The team will review the labels and make any necessary changes.

@legzo
Copy link
Author

legzo commented Feb 7, 2019

@jimschubert , @dr4ke616 : what's your take on that ?

@jimschubert
Copy link
Member

@legzo I do think this would be considered a bug. There's always a workaround with type mappings in that you can specify them on the command line. Some generators may set certain mappings in such a way that user overrides aren't supported (as with Kotlin client json types).

If you're able to open a PR, that would be awesome. I'm in a crunch at work and it's been taking away from my open source contrib time.

@jimschubert
Copy link
Member

I've tagged this as client/server related, since this is in the base class. Will evaluate the full impact later.

@legzo
Copy link
Author

legzo commented Feb 8, 2019

Hi @jimschubert, thanks for your feedback.

As a matter of fact I overrid the mapping in the config of the generator, so there is a work around. However I find it deceptive that out of the box Jackson is not able to deserialize a model that is propertly typed and formatted in the json.

I'll make a PR and you'll decide what to do with it :)

Thank you for your open-source contrib by the way. Much appreciated.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants