feltech
commented
10 months ago Still in the midst of reviewing, but had a concern/idea about the approach.
We're hardcoding specific behaviour into BAL making it less puppetable/configurable. I wondered if we could/should accomplish similar behaviour in a more scripted way.
Thinking back, we did briefly discuss this, but I think worth double-checking that mandating specific non-configurable workflows is what we want.
When I demoed the new version traits using BAL (obviously prior to this PR) I simply created multiple entity entries in the JSON, one for each 'version', and hand coded the version trait properties within each.
In our MaxR experiments we used an "aliases" map to hand code /best to map to another entity. Similar could be done for /latest, perhaps with specific overrides (e.g. "latest" specifiedTag).
We already have support for hand coding related reference queries (though it may need extending to handle filtering).
Publishing could be data-driven too, e.g. a mapping of input reference to (list of) output reference and database delta, where the delta adds the new entity with default traits (e.g. Version), updates aliases, etc.
Life would be easier if the BAL database was a Python file so we could use MediaCreation to construct the dict. Would be great if MediaCreation was only a dependency of the library file, rather than the whole project. I guess there's nothing stopping us from constructing the dict in Python and dumping out the JSON.
foundrytom
~No code changes since draft review aside from mollifying
pylint~. Future proofed the versions relationship handling here.Sleepy head is struggling to work out what should be in commit messages, let me know if you can think of any that need explaining/calling out.
Closes #49