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
This code is in many of the sample applications. The engine_finder() is typed as Engine, which is an abstract class. It doesn't however provide an (@abstract)method for start_connection_pool() and close_connection_pool(). These methods only exist in the concrete subclass for Postgres. Hence vscode/pylance complain about non-existing methods.
I can do a PR, but am unsure about best solution.
Personally I would add these methods as normal methods to the Engine class, just providing a colored_warning() that pooling is not implemented for the provided engine.
Alternatively all sample programs using the connection pool could be changed like:
Adding a method to Engine is a good idea. As you say, it can just output a warning, and should be overridden in child classes.
Even with that change, Pylance might still complain because engine_finder can potentially return None. So the example code should be like you suggested:
This code is in many of the sample applications. The
engine_finder()
is typed as Engine, which is an abstract class. It doesn't however provide an (@abstract)method forstart_connection_pool()
andclose_connection_pool()
. These methods only exist in the concrete subclass for Postgres. Hence vscode/pylance complain about non-existing methods.I can do a PR, but am unsure about best solution.
Personally I would add these methods as normal methods to the Engine class, just providing a colored_warning() that pooling is not implemented for the provided engine.
Alternatively all sample programs using the connection pool could be changed like:
The text was updated successfully, but these errors were encountered: