Sibling keys (design dead-end)

[learner-long-life]

To allow forked deploys for parallel reproducible testing and public forks, it is useful to store some (parent) keys at the parent level, and the child keys as contained files in the parent directory with the same basename.

Example directory structure

  ContractName-deploy/
    forkTime1.json # contains child keys for forkTime1
    forkTime2.json # contains child keys for forkTime2
  ContractName-deploy.json # contains parent keys that are equally applicable to forkTime1 and forkTime2

This would be the result of running the following writes

set('ContractName-deploy/forkTime1', Map({a:1}))
set('ContractName-deploy/forkTime2', Map({b:2}))
set('ContractName-deploy', Map({c:3}))

The read semantics seem clear, merging the child keys and the parent keys from the sibling directory+file.

get('ContractName-deploy') ->
  {
    'forkTime1': {'a': 1},
    'forkTime2': {'b': 2},
    'c': 3
  }

However, now the write semantics are confusing. If we write to the parent key, should we now check all the child keys and create JSON files for them? What if previous child keys are now missing? How do we decide which child keys to put into JSON files versus making them parent keys in the sibling file?

In general, this violates a principle of "There's only one way to do it". The preferred way to solve this is to explicitly create a "parent" child, in this case, with a perhaps redundant name of 'deploy'

set('ContractName-deploy/forkTime1', Map({a:1}))
set('ContractName-deploy/forkTime2', Map({b:2}))
set('ContractName-deploy/deploy', Map({c:3}))

The read semantics are still clear, with one more level of indirection for the parent keys that used to be in the sibling file

get('ContractName-deploy') ->
  {
    'forkTime1': {'a': 1},
    'forkTime2': {'b': 2},
    'deploy': {'c': 3},
  }

Long story short, this is a design dead-end and we record it here for completeness, and will delete the branch and close this PR as won't fix.