You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
It would be really nice to have an --unload command to nycdb that simply undoes anything that --load does.
The simple version of this could just drop the tables mentioned in the YAML file, but a more awesome version would also be able to drop any derived tables (e.g. those hpd_registrations_grouped_by_bbl or whatever) and functions that were created... I have some code over in JustFixNYC/nycdb-k8s-loader that parses the actual SQL files to glean some of this information, if it'd be helpful, but maybe that's complicating things too much.
The text was updated successfully, but these errors were encountered:
Sure, why not! Yup, it'd mostly be just dropping tables and functions.
By the way, you don't have to parse the sql files, verify.py has a list of tables that are created for each dataset (including the derived ones). I'll admit, though, that it's not the most obvious place for that constant, so perhaps we should put it somewhere else or include that information in the yaml files instead.
Oooh yeah!! I really like the idea of putting verification-related metadata in the YAML file. Verification isn't documented in the ADDING_NEW_DATASETS.md guide and I have no idea how to do it... and to the extent that one of the best sources of ad-hoc documentation on our datasets so far is the YAML files, this would make it easier for folks to understand what derived tables are created for datasets!
It would be really nice to have an
--unload
command to nycdb that simply undoes anything that--load
does.The simple version of this could just drop the tables mentioned in the YAML file, but a more awesome version would also be able to drop any derived tables (e.g. those
hpd_registrations_grouped_by_bbl
or whatever) and functions that were created... I have some code over in JustFixNYC/nycdb-k8s-loader that parses the actual SQL files to glean some of this information, if it'd be helpful, but maybe that's complicating things too much.The text was updated successfully, but these errors were encountered: