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

handle uri formatted strings #1568

Open
martijnhoekstra opened this issue Aug 26, 2022 · 1 comment
Open

handle uri formatted strings #1568

martijnhoekstra opened this issue Aug 26, 2022 · 1 comment
Labels
core Pertains to guardrail-core help wanted Easy to moderately difficult issues that don't require deep knowledge or architectural thought scala Broadly concerning Scala code generation or the generated Scala code

Comments

@martijnhoekstra
Copy link
Contributor

URI is a valid pre-defined format for schemas, per https://json-schema.org/draft/2020-12/json-schema-validation.html#section-7.3.5

For schemas of type string with format uri, guardrail could generate something more restrictive than String, for example java.net.URI or an org.http4s.Uri

@blast-hardcheese
Copy link
Member

Thanks for the report! Before I go into what could be changed in guardrail, are you aware of the x-scala-type vendor extension? If you x-scala-type: java.net.URI, it looks like the default Encoder and Decoder from circe should be picked up. That could get you on your way while we hash out the specifics of this ticket.


Looking at the most recent section in the OAI 3.1.0 spec on Data Types they say

Data types in the OAS are based on the types supported by the JSON Schema Specification Draft 2020-12.

I see that the document you linked is listed as a footnote, but it seems non-authoritative when it comes to the section on data types -- How did you come across the json-schema-validation spec in the context of guardrail not supporting "type": "string", "format": "uri"? I wonder if there are other types and formats that we should be supporting.

Beyond clarification of the specification, I don't have the time required to do the implementation right now, but if you (or somebody else) wants to take a crack at it...

  • SwaggerUtil contains the type/format mapping
  • LanguageTerm contains the interface for defining new types
  • ScalaGenerator and JavaGenerator contain the mappings for underlying types (Probably just do STRING_TYPE for Java until somebody asks for java.net.URI or others to be supported)
  • Finally, there's probably going to need to be a Show[java.net.URI] defined back in ScalaGenerator.

There's an unfortunate design choice that hadn't come up before now which is that since ScalaGenerator is the thing determining the types, but ScalaGenerator doesn't know anything about the framework that was selected, I don't believe there's an easy way to wire up http4s' Uri. Possibly by way of deferral to a different interface or by defining the uriType in a separate place from all the other types... not great.

@blast-hardcheese blast-hardcheese added help wanted Easy to moderately difficult issues that don't require deep knowledge or architectural thought scala Broadly concerning Scala code generation or the generated Scala code core Pertains to guardrail-core labels Aug 27, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
core Pertains to guardrail-core help wanted Easy to moderately difficult issues that don't require deep knowledge or architectural thought scala Broadly concerning Scala code generation or the generated Scala code
Projects
None yet
Development

No branches or pull requests

2 participants