QA finding: every row of crono-export servings --format json includes a Day field whose value is always null:
$ crono-export servings --since 90d --format json | jq '[.[] | .Day] | unique'
[
null
]
This is documented in the prime GOTCHAS ("'servings' rows have a 'Day' field that is always null — use 'RecordedTime'"), so it's a known wart — but documenting it doesn't make it less wrong. Consumers waste a key on a sentinel; jq recipes that introspect schemas have to special-case it.
Two reasonable fixes:
- Drop the field from
ServingRecord (json tag with omitempty or remove entirely). Cleanest.
- Populate it from RecordedTime's local-date portion if it's meant to be a denormalized convenience. Keeps the field but makes it useful.
I lean #1 — RecordedTime already carries the info, the GOTCHAS note already tells users to use it.
Once fixed, remove the corresponding line from cmd/prime.go GOTCHAS.
Severity: trivial (cosmetic schema cleanup)
QA finding: every row of
crono-export servings --format jsonincludes aDayfield whose value is always null:This is documented in the
primeGOTCHAS ("'servings' rows have a 'Day' field that is always null — use 'RecordedTime'"), so it's a known wart — but documenting it doesn't make it less wrong. Consumers waste a key on a sentinel; jq recipes that introspect schemas have to special-case it.Two reasonable fixes:
ServingRecord(json tag withomitemptyor remove entirely). Cleanest.I lean #1 — RecordedTime already carries the info, the GOTCHAS note already tells users to use it.
Once fixed, remove the corresponding line from
cmd/prime.goGOTCHAS.Severity: trivial (cosmetic schema cleanup)