Schema default value of object within array is not being applied.
- Dominant language
- Go
- Stars
- 1.9k
- Forks
- 167
- PR merge metrics
- No merged PRs in 30d
Description
**What steps did you take:**
Create a directory called `resources` for resource files.
In `resources/00-schema.yaml` add:
```
#@data/values-schema
---
#@schema/type any=True
spec:
staticPasswords:
- username: ""
email: ""
hash: ""
userID: ""
```
In `resources/01-dummy.yaml` add:
```
#@ load("@ytt:data", "data")
---
staticPasswords:
#@ for user in data.values.spec.staticPasswords:
- username: #@ user.username
email: #@ user.email
hash: #@ user.hash
userID: #@ user.userID or "XXX"
#@ end
```
Create a `values.yaml` file containing:
```
spec:
staticPasswords:
- email: "admin@example.com"
hash: "$2a$10$2b2cU8CPhOTaGrs1HRQuAueS7JTT5ZHsHSzYiFPm1leZck7Mc8T4W"
username: "admin"
#userID: ""
```
Run the command:
```
ytt -f resources/ --data-values-file values.yaml
```
**What happened:**
It generates the error:
```
ytt: Error:
- struct has no .userID field or method
in
01-dummy.yaml:9 | userID: #@ user.userID or "XXX"
```
**What did you expect:**
Expected it to generate:
```
staticPasswords:
- username: admin
email: admin@example.com
hash: $2a$10$2b2cU8CPhOTaGrs1HRQuAueS7JTT5ZHsHSzYiFPm1leZck7Mc8T4W
userID: XXX
```
**Anything else you would like to add:**
The problem is triggered due to the use of:
```
#@schema/type any=True
```
on the `spec` property in the schema file. If you comment out or remove that line you get the desired result.
That is, using a schema file of:
```
#@data/values-schema
---
spec:
staticPasswords:
- username: ""
email: ""
hash: ""
userID: ""
```
gives the expected result.
Trying to reverse the impact of `schema/type any=True` by applying `schema/type any=False` to the nested `staticPasswords` property doesn't help. That is, following still fails.
```
#@data/values-schema
---
#@schema/type any=True
spec:
#@schema/type any=False
staticPasswords:
- username: ""
email: ""
hash: ""
userID: ""
```
Even though `schema/type any=True` is used at a higher level in settings hierarchy, would have expected default values to still be applied and `userID` added to object in array even when not supplied.
Note that the original intent here was to not fail when unexpected properties were supplied in `spec` for various reasons, but still wanted schema type checks to otherwise apply.
For example, didn't want it to fail if was supplied:
```
spec:
staticPasswords:
- email: "admin@example.com"
hash: "$2a$10$2b2cU8CPhOTaGrs1HRQuAueS7JTT5ZHsHSzYiFPm1leZck7Mc8T4W"
username: "admin"
#userID: ""
unexpectedField: xxx
```
which would otherwise yield:
```
ytt: Error: Overlaying data values (in following order: additional data values):
One or more data values were invalid
====================================
values.yaml:
|
7 | unexpectedField: xxx
|
= found: unexpectedField
= expected: (a key defined in map) (by 00-schema.yaml:6)
= hint: declare data values in schema and override them in a data values document
```
**Environment:**
- ytt version (use `ytt --version`):
```
$ ytt --version
ytt version 0.37.0
```
- OS (e.g. from `/etc/os-release`):
```
$ uname -a
Darwin xxx 20.6.0 Darwin Kernel Version 20.6.0: Mon Aug 30 06:12:21 PDT 2021; root:xnu-7195.141.6~3/RELEASE_X86_64 x86_64
```
cc @jorgemoralespou
---
Vote on this request
This is an invitation to the community to vote on issues, to help us prioritize our backlog. Use the "smiley face" up to the right of this comment to vote.
👍 "I would like to see this addressed as soon as possible"
👎 "There are other more important things to focus on right now"
We are also happy to receive and review Pull Requests if you want to help working on this issue.
Contributor guide
Research direction
Reproduce the issue with resources/00-schema.yaml, resources/01-dummy.yaml, values.yaml, and `ytt -f resources/ --data-values-file values.yaml`. Compare behavior with and without `#@schema/type any=True`, then trace the schema and data-values handling that determines defaults for objects in arrays. Done means the command emits userID: XXX while still accepting unexpectedField under spec.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- go
- Domain
- cli
- Issue type
- Bug
- Difficulty
- 4/5
- Estimated time
- 3-5 days
- Activity status
- Stale
- Clarity
- Mostly clear
- Newbie friendliness
- 35/100