Allow using nicknames for body definitions#862
Conversation
f51c63b to
b417562
Compare
…ild rather than OperationId.manipulate This means it'll use route nicknames if those are available. It also means route parameters will be used in the definition names.
MoveParams.build_definition returns the passed in name, so name and referenced_definition were always the same value.
b417562 to
2055195
Compare
|
I'm not quite sure why the build is erroring on Ruby@head, seems unrelated to the changes in this PR? |
|
I'm still seeing the same failure on Either way I don't think this should be a blocker for this PR 🙇🏼 |
|
@LeFnord anything else I should add to this PR, or does this look good to go? 🙇🏼 Thanks! |
888f46d to
c1bf305
Compare
|
|
thanks @magni- … it seems it changes something so maybe add an entry to UPGRADING.md and one question: should we add |
👍🏼
Good question. The build works fine on all released versions of Ruby, it's just the upcoming 3.2 (which won't be released for another 5 months) which had issues. If we add an explicit requirement, might as well make it to |
|
@LeFnord I've updated |
c1bf305 to
2ddb537
Compare
|
@magni- … yeah, definitely will it be 1.5.0 … besides that it looks good … great job, tahnk you |
I think it makes more sense to update the requirement in |
|
ok makes sense :) |
|
@LeFnord could you release this to RubyGems? Thank you! 🙇🏼 |
|
done |
* Fix typo * Refactor MoveParams.parent_definition_of_params to use OperationId.build rather than OperationId.manipulate This means it'll use route nicknames if those are available. It also means route parameters will be used in the definition names. * Simplify MoveParams.build_body_parameter MoveParams.build_definition returns the passed in name, so name and referenced_definition were always the same value. * Fix Rubocop offenses * Fix old reference to Travis CI in CONTRIBUTING * Fix CHANGELOG * Update CHANGELOG and UPGRADING
* Fix typo * Refactor MoveParams.parent_definition_of_params to use OperationId.build rather than OperationId.manipulate This means it'll use route nicknames if those are available. It also means route parameters will be used in the definition names. * Simplify MoveParams.build_body_parameter MoveParams.build_definition returns the passed in name, so name and referenced_definition were always the same value. * Fix Rubocop offenses * Fix old reference to Travis CI in CONTRIBUTING * Fix CHANGELOG * Update CHANGELOG and UPGRADING
* Fix typo * Refactor MoveParams.parent_definition_of_params to use OperationId.build rather than OperationId.manipulate This means it'll use route nicknames if those are available. It also means route parameters will be used in the definition names. * Simplify MoveParams.build_body_parameter MoveParams.build_definition returns the passed in name, so name and referenced_definition were always the same value. * Fix Rubocop offenses * Fix old reference to Travis CI in CONTRIBUTING * Fix CHANGELOG * Update CHANGELOG and UPGRADING
We have an API defined roughly as follows:
We noticed the docs for our API were incorrect. Both
paths.things.put.parameters.0.schema.$refandpaths.things{id}.put.parameters.1.schema.$ref(parameters.0is for the path:idparameter) are pointing to the same thing:"#/definitions/putThings. It turns out theput-thingbody parameter definition is overriding the previousput-thingsbody parameter definition, rather than defining its own thing. It's been a while since I've dug into thegrape-swaggercode, so I went with the (IMO) easy fix: using route nicknames if they're available to name the body parameter definitions.Edit: Based on the changes I had to make to get specs to pass, this change would also have solved our issue without using route nicknames, since the references become
putTestsandputTestsId.Related issue: ruby-grape/grape#2035