The catalogdb models are defined for operations, where all the tables exist. The copy in pipelines has only a subset for the tables. Currently the import of the models for catalogdb works but many of the models are orphan and fail when a query is attempted, as there is no associated table. In SQLA this causes an error that requires a rollback.
We should find a better way to handle this. Ideally we would avoid creating the models, or remove them once we verify that the table does not exist. But this requires an active connection, at which point the model has already been defined. Removing the model from the module is not trivial since it depends on how the module or class were imported.
The
catalogdbmodels are defined foroperations, where all the tables exist. The copy inpipelineshas only a subset for the tables. Currently the import of the models forcatalogdbworks but many of the models are orphan and fail when a query is attempted, as there is no associated table. In SQLA this causes an error that requires a rollback.We should find a better way to handle this. Ideally we would avoid creating the models, or remove them once we verify that the table does not exist. But this requires an active connection, at which point the model has already been defined. Removing the model from the module is not trivial since it depends on how the module or class were imported.