Parameters are stored inside json/yaml files inside assnake_db. Assnake determines which parameters to use from the wildcard_str (.../tmtic_{params}/..). File that contains this parameters is taken from assnake_db by its name.
Q: Should we store this file also inside the folder with generated results?
A: I think yes, this way the file can be pushed to git and it will be easier to get it for higher order system. Also parameters will be saved if the assnake_db will be deleted.
We also should we able to pickup this file from result folder and put it into db. If the name is not unique and the contents of params.yaml file is different, for now just add counter like params1.yaml
Should we store params not by name but by short hash? It will help to avoid non unique names problem, but at the same time reduce human readability. Since we will store params with uuid-v4 in higher order system anyway, there is no much sense in it.
Parameters are stored inside json/yaml files inside
assnake_db. Assnake determines which parameters to use from the wildcard_str (.../tmtic_{params}/..). File that contains this parameters is taken fromassnake_dbby its name.Q: Should we store this file also inside the folder with generated results?
A: I think yes, this way the file can be pushed to git and it will be easier to get it for higher order system. Also parameters will be saved if the
assnake_dbwill be deleted.We also should we able to pickup this file from result folder and put it into db. If the name is not unique and the contents of params.yaml file is different, for now just add counter like params1.yaml
Should we store params not by name but by short hash? It will help to avoid non unique names problem, but at the same time reduce human readability. Since we will store params with uuid-v4 in higher order system anyway, there is no much sense in it.