Supporting metadata tables made a lot of sense at the beginning of the project, but with HyraxQL and dataset class getter methods we can treat metadata in a more consistent way than we did before. At this point they feel like a sidecar on the rest of the dataset and are treated differently from the rest of the data.
We should review the locations where we make use of metadata (hopefully just HSCDataset and possibly LSSTDataset, and implement regular or dynamically generated get_<col_name> methods for the metatdata tables associated with the datasets.
Regarding visualization specifically, we wouldn't need to load the specific columns from metadata before hand, we could augment the UI such that a selectable list of available columns is shown that would 1) allow the user to see all available metadata/columns available 2) update the selected columns in real time (since visualize can interface with HyraxQL on the backend without the user having to modify configurations)
Supporting metadata tables made a lot of sense at the beginning of the project, but with HyraxQL and dataset class
gettermethods we can treat metadata in a more consistent way than we did before. At this point they feel like a sidecar on the rest of the dataset and are treated differently from the rest of the data.We should review the locations where we make use of metadata (hopefully just HSCDataset and possibly LSSTDataset, and implement regular or dynamically generated
get_<col_name>methods for the metatdata tables associated with the datasets.Regarding visualization specifically, we wouldn't need to load the specific columns from metadata before hand, we could augment the UI such that a selectable list of available columns is shown that would 1) allow the user to see all available metadata/columns available 2) update the selected columns in real time (since visualize can interface with HyraxQL on the backend without the user having to modify configurations)