-
Notifications
You must be signed in to change notification settings - Fork 403
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
[gen] normalized fields with annotations holding original field name #3069
Conversation
zio-http-gen/src/test/scala/zio/http/gen/scala/CodeGenSpec.scala
Outdated
Show resolved
Hide resolved
bd080ac
to
ded2c32
Compare
zio-http-gen/src/test/resources/inline_schema_weird_field_names.yaml
Outdated
Show resolved
Hide resolved
@zio.schema.annotation.validate[Int](zio.schema.validation.Validation.greaterThan(0)) quantity: Int, | ||
@zio.schema.annotation.validate[Double](zio.schema.validation.Validation.greaterThan(-1.0)) price: Double, | ||
@validate[Int](Validation.greaterThan(0)) quantity: Int, | ||
@validate[Double](Validation.greaterThan(-1.0)) price: Double, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Not related to current PR, but the float/double validation logic is faulty.
minimum 0
does not mean > -1.0
Since e.g: -0.5 > -1.0
, but does not adhere to original minimum requirement.
CC @987Nabil
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
True. But I think this is unsolvable then. There is no way to translate it to zio-schema correctly right now. We probably need to add new validations to zio schema
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@987Nabil in second thought, perhaps you need a change for greaterOrEqualTo, but we can still use java.lang.Math.nextDown
(or nextAfter
) to get the closest representable floating point number that is smaller (or larger) than the input.
It might be ugly, e.g:
@ java.lang.Math.nextDown(0f)
res0: Float = -1.4E-45F
but at least it'll be (effectively) correct.
WDYT?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think that works work. But I would not write out the number, but generate the expression
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yup...
@validate(Validation.greaterThan(Math.nextDown(0f)))
Would be much better (and understandable) than generating weird epsilons
Codecov ReportAll modified and coverable lines are covered by tests ✅
❗ Your organization needs to install the Codecov GitHub app to enable full functionality. Additional details and impacted files@@ Coverage Diff @@
## main #3069 +/- ##
=======================================
Coverage 65.57% 65.57%
=======================================
Files 157 157
Lines 10251 10251
Branches 1918 1918
=======================================
Hits 6722 6722
Misses 3529 3529 ☔ View full report in Codecov by Sentry. |
* unless original field is defined in the specialReplacements map. | ||
*/, | ||
specialReplacements: Map[String, String], /* | ||
* When normalization is enabled, a heuristic parser will attempt to normalize field names. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Map can be used also when auto normalization is not enabled. I should amend the documentation to be clearer
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
If specialReplacements
can be used out side of normalization, does it belong in the normalization config?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I meant of course it's part of normalization. but it overrides auto normalization (i.e: using the parser to construct a different term).
Normalization has 2 modes:
- manual replacements (user control exactly what to replace with what)
- automatic (a heuristic parser will try to do the best it can)
both fall under normalization.
Perhaps I should rename as: automaticEnabled
& manualReplacements
?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Would turning the automated off lead to invalid code? Should it be always on? And the manual just be tried first, if the map is not empty?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
no, not at all.
These are decoupled.
having e.g. auto off, and replacement on can yield from e.g:
Thing:
type: object
properties:
S/N:
type: string
format: uuid
N_A_M_E:
type: String
with only replacing "N_A_M_E" -> "name"
something like:
case class Thing (
`S/N`: UUID,
name: String
)
which is perfectly fine.
zio-http-gen/src/main/scala/zio/http/gen/openapi/EndpointGen.scala
Outdated
Show resolved
Hide resolved
…n for zio#3031 (which will add more annotations). Specifically: use imports insteads of inlined FQCN when adding annotations
* add new configurations needed for normalization of fields
…r less), since previous implementation was slooooooooow. * propagate configuration to use fields normalization * implement & add relevant annotation when field name been normalized * test suite for normalization logic * add test to verify annotations are add correctly
…fields (and imports) when rendering
* Restore test cases fields original order * Reduced normalized test to have only 4 fields (up to 4 fields, order is consistent, since Map1, …, Map4 implementation is consistent between scala versions. More fields aren't guaranteed to have consistent order)
* renamed config normalizations setting to be clearer * moved comments to be scaladoc in configuration (scalafmt kep messing this up, so I've set '//format: off' - should we configure 'docstrings.style = keep' in scalafmt.conf to avoid it messing up nicely formatted scaladocs?)
6ab7398
to
7ff855c
Compare
… on different lines?
also, re-run CI since seems to be affected by a flaky test: Client / ClientSpec / request can be timed out manually while awaiting connection
PR ready for review
fixes #3031
/claim #3031