I have a script that performs database operations alongside an alembic API call to upgrade a newly created database to head. I am having an issue with a python logger instance where logs are written to a file using a module level logger.
Then the script invokes alembic.config.main(argv=alembic_args)
to run a migration. However, every log statement after the alembic call, using the original logger instance, isn't written to the expected log file.
Here is an example script that reproduces the behavior.
#!/usr/bin/env python3
import logging
import os
import alembic.config
from .utilities import get_migration_dir
logging.basicConfig(filename='test.log',
level=logging.DEBUG)
CUR_DIR = os.path.dirname(__file__)
LOG = logging.getLogger('so_log')
LOG.info('Some stuff')
LOG.info('More stuff')
alembic_config = (
'--raiseerr',
'upgrade', 'head'
)
os.chdir(get_migration_dir())
alembic.config.main(argv=alembic_config)
os.chdir(CUR_DIR)
LOG.debug('logging after alembic call.')
LOG.debug('more logging after alembic call.')
print('Code still running after alembic')
Log file output
INFO:so_log:Some stuff
INFO:so_log:More stuff
stdout
INFO [alembic.runtime.migration] Context impl PostgresqlImpl.
INFO [alembic.runtime.migration] Will assume transactional DDL.
print statement before alembic
Code still running after alembic
It seems as though the logger instance, LOG
, is losing context or being directed elsewhere after calling the alembic API.
Also, I've tried running the alembic call in a separate thread which yielded the same result. What I expect to happen should be that log statements continue to write to the specified file after using alembic for migrations but that is not happening. And further, it's actually breaking the LOG
instance for any code that's called afterward; Unless I'm just missing something here.