swh.core.cli.db module#
- swh.core.cli.db.handle_cmd_args(cfg: Dict[str, Any], module: str, is_path: bool = False, do_all: bool = False, dbname: str | None = None, config_key: str | None = None) List[Tuple[str, str, type | None, str, Dict[str, Any]]][source]#
Helper function to build the list of backends to handle in a cli command
- For each identified backend, returns a tuple:
(package, module, backend_class, cnxstr, cfg)
- where:
package: the (swh) package this backend is implemented in (e.g. ‘storage’, ‘scheduler’ etc.)
module: the (full path) module in which the backend class can be found (e.g. ‘swh.storage.postgresql.storage’)
backend_class: the class implementing the backend,
cnxstr: the (libpq) connection string to the database,
cfg: the config structure in which this backend is configured; if the backend is defined in a nested configuration, this is only the most specific config structure for this backend.
For each backend, the code implementing the backend class needs to be registered in the swh.<package>.classes entry point under the cfg[“cls”] name. However, there is bw compatibility for swh packages not yet updated to register these backends in the entry points.
If dbname is given, return only one element in the list, with a config made of {‘cls’: ‘postgresql’, ‘db’: dbname}.
If do_all is True, look for every backend in the configuration (cfg) under the section module.
If module is a simple word (‘storage’, ‘scheduler’, etc.), look for the last db backend found in the config file under the module section.
If is_path is True, interpret the ‘module’ as the path to the config entry to use in the config file.
If module is an actual module path (e.g. ‘storage.proxies.masking’), then dbname must be given and the configuration is not looked for in the config file.
Note: this rather complex logic will be simplified when all the swh packages are updated and do not need bw compat handling code any more.