-
Notifications
You must be signed in to change notification settings - Fork 17
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
Ambigous path and query parameters #56
Comments
Hey Eli, please pardon the delayed reply! This does seem quite unfortunate, considering that the documentation for the parameters indicates that they are clearly intended for different purposes. This seems like an odd edge case -- I'd honestly say this is more of a bug with the specification, as the path parameter name could be changed to disambiguate without needing to alter the form parameter. If guardrail generates bogus code, maybe we could emit a warning or an error guiding the user on how to resolve the issue (possibly providing If we want to support this kind of behavior, ensuring stable ordering of parameters and suffixing with some sort of disambiguating key, bounded by some context, seems reasonable -- A few users have run into issues where they had no control of specifications given to them, with the unfortunate side effect of guardrail not being able to be used at all. This seems like it may fall into that bucket. Given your experience with the problem, what would you like to see happen? Hopefully what you need is something that could be broadly applicable to other use cases as well, avoiding one-off hacks that could end up biting us in the future? |
(Also, this should probably be a discussion in https://github.com/twilio/guardrail, this is just the SBT plugin, as I've just realized) |
plugin, as I've just realized)
changed to disambiguate without needing to alter the form parameter.
Yep thats definitely me ^_^. The k8s spec is 4.5MB in size - no human can control that beast!
The disambiguation way would solve this problem for me. I did it manually by editing the api.json, using something like In fact, the client Guardrail generated works! Check it out: https://github.com/soujiro32167/sk8s/blob/master/modules/examples/src/main/scala/com/example/App.scala |
Wild, great to hear! So, looking at I'm trying to get debug logging working, so unfortunately if you're interested in poking around the best way to do so is to just use Funnily enough, your spec helped find a regression for the 0.58.0 release -- I don't have many tests for extraordinarily large specifications currently, so it was very helpful to be able to bisect using yours. |
(See guardrail-dev/guardrail#600 (comment) for timing benchmarks) |
Hey Devon!
I'm back to the crazy plan to generate a client for the Kubernetes API. Thanks again for all the help last Lambdaconf =]
Here is a snippet of the generated client that does not compile:
The
path
parameter appears twice, as bothString
andOption[String]
. It is used both as a path parameter and query parameter.Below is the corresponding OpenAPI snippet. What happens is that they define a path parameter with the same name as a query parameter:
I'd be happy to help with resolution, given some direction
Cheers,
Eli
The text was updated successfully, but these errors were encountered: