Wrap face analysis algorithms in Docker #22
Conversation
This prevents potential unexpected behavior due to volumes sticking around between runs.
This change also makes it easier to override environment variables, e.g. to configure a queue per test run.
| from sqlalchemy.orm import sessionmaker | ||
| from sqlalchemy import create_engine | ||
| from ..log import get_logger | ||
| from ..settings import (MYSQL_USER, MYSQL_PASSWORD, MYSQL_DATABASE, |
There was a problem hiding this comment.
In previous PRs, ..imports were replaced with module.module.module. Which should we choose for consistency?
There was a problem hiding this comment.
I'll fix up all the imports in a follow up PR, keeping local consistency for now. In general, absolute imports are preferred since they are more explicit.
| as Serializer, BadSignature, SignatureExpired) | ||
| from .database_manager import DatabaseManager | ||
| from .database_manager import get_database_manager | ||
| from ..settings import TOKEN_EXPIRATION, TOKEN_SECRET_KEY |
There was a problem hiding this comment.
In previous PRs, ..imports were replaced with module.module.module. Which should we choose for consistency?
| self.engine.dispose() | ||
|
|
||
|
|
||
| @lru_cache(maxsize=1) |
There was a problem hiding this comment.
Is the purpose of this decorator (maxsize=1, on a function with no arguments) to treat the DatabaseManager class as a singleton? If so, is this a better way than explicitly making the class a singleton, so it is not accidentally misused?
There was a problem hiding this comment.
Yes, this is the standard/stdlib way to create a singleton.
There was a problem hiding this comment.
The problem I foresee with this method is that I could still make as many different instantiations of DatabaseManager as I would like. If we made the class an actual singleton (https://www.python-course.eu/python3_metaclasses.php) (could use metaclasses as the link describes, but not totally necessary), then this problem would be alleviated.
There was a problem hiding this comment.
In dynamic languages you can always shoot yourself in the foot if you want to... it's just about making "doing the right thing" easy. Ideally the design would be changed to avoid the need for the singleton (e.g. currently there are lots of nested sessions etc flying around) but that's a bigger change than I'm willing to make right now.
The interface to the algorithm Docker is as follows:
docker run the_container ...{"faceVectors":[[...],[...],...]}to stdout.See #3