Details
-
Type:
Story
-
Status: To Do
-
Resolution: Unresolved
-
Fix Version/s: None
-
Component/s: daf_butler
-
Labels:
-
Team:Data Release Production
-
Urgent?:No
Description
My favored resolution to the visit_system + visit.seqnum problem is to make it possible for an instrument to specify a default visit_system (along with DM-33819), which would be used in any context where one was not given explicitly (particularly data ID lookups and WHERE expressions). That's a lot like how governor dimension defaulting works, but it's enough different (it comes from a governor dimension, not from data ID usage in datasets/collections) that we can't just reuse all of that code.
My general idea is to make it possible to declare which other dimensions a governor supplies a default for in the dimensions configuration, e.g.
instrument:
|
...
|
defaults: ["visit_system"] |
That would add a "default_visit_system" column to the instrument table that would be populated at instrument registration. This would not have a FK constraint to avoid cycles (we wouldn't gain much from a FK anyway).
That should be enough state to support logic in RegistryDefaults to do the work.
This would be a schema change because of the need to update the (e.g.) instrument table.
Attachments
Issue Links
Activity
I think I might go add the config support for this to DM-34589 now; that will give us a head start on removing that hard-coding someday (or at least relegating it to a "if version < X" branch) in the future. I'll take this out of In Progress for now and we can keep it around for fully implementing this without hard-coding someday.
We ended up implementing this in a different way (
DM-33942) in that we explicitly added visit_system to the instrument record (and did not call it default_visit_system) rather than trying to add extra logic paths. It does though mean that the implementation does not know that visit_system is anything special and the Butler fallback logic has to hard code this.