resolve default through ref unless default exists at same level#69
resolve default through ref unless default exists at same level#69jwetzell wants to merge 2 commits intogoogle:mainfrom
Conversation
|
Thanks for your pull request! It looks like this may be your first contribution to a Google open source project. Before we can look at your pull request, you'll need to sign a Contributor License Agreement (CLA). View this failed invocation of the CLA check for more information. For the most up to date status, view the checks section at the bottom of the pull request. |
|
CLA has been signed! |
|
not sure who to bother for a review but tagging the highest contributor! @jba |
| } | ||
|
|
||
| subschemaDefault := subschema.Default | ||
| subschemaInfo := st.rs.resolvedInfos[subschema] |
There was a problem hiding this comment.
Can this be nil? (I honestly don't remember.) Either way, it's safer to add a check on 730.
There was a problem hiding this comment.
Before you do, see if you can write a failing test.
There was a problem hiding this comment.
I tried to write a test that would get the resolved reference to be nil but it would always be caught by some earlier piece (json reference resolver or the checkStructure part in validate). Nil checks added though.
2 participants
This library does not follow a
$refwhen applying defaults. I've added test cases for the two scenarios I can think of where there is both and$ref(with it's owndefault) and adefaultat the same level and when there is just a$refwith it's owndefaultinside. In this case the solution I have implemented only searches the$refif there is nodefaulton the subschema. Essentially meaning a subschema can override adefaultinside the$ref.I did look through the JSONSchema reference about how
defaultshould be handled and found this blurb so I guess it is up to tooling.Either way is trivial to implement but it should at least be noted I guess.