Well what makes no sense is why these mappers and classes would be
present at all. These classes are strictly defined within an alembic
migration, and make **no** callouts to any other mapped structures in
the application, correct? If so, when the module is garbage
collected, all of the th
I forgot to mention, we’re not using clear_mappers().
Thanks,
Will
> On 21 Feb 2016, at 19:19, Will Angenent wrote:
>
> Hi Mike,
>
> Thanks for your quick response yet again! Here’s the stack trace.
>
> tests/integration/test_database.py:14: in test_database_is_up_to_date
> create_test_db
Hi Mike,
Thanks for your quick response yet again! Here’s the stack trace.
tests/integration/test_database.py:14: in test_database_is_up_to_date
create_test_db(session)
__init__.py:111: in create_test_db
pd_utils.do_import(dtype='locations', ifile=yaml_file)
../utils/provider_data/__init_
Hi there -
Can you post a stack trace, and also is your test suite making use of
clear_mappers() ?
The sys.modules activity is not really the primary cause, it's that alembic
makes use of a module object in a temporary way.
> On Feb 21, 2016, at 1:48 PM, Will Angenent wrote:
>
> Hi,
>
>
Hi,
We had this interesting issue recently, and I've been trying to figure out
if we deserve this, if this is simply unavoidable, or whether it can be
considered a bug. We're using python 2.7.6, sqlalchemy 1.0.12 and alembic
0.8.4.
Summary:
This statement in alembic.util.pyfiles.load_python_f
On 02/21/2016 12:47 PM, Uri Okrent wrote:
I did a bit more digging. It looks like utils.counter() is used in two
places that are causing me hangs in multiprocess subprocesses. In
instances() in order to assign a unique runid to the QueryContext, and
in session instantiation in order to assign
I did a bit more digging. It looks like utils.counter() is used in two
places that are causing me hangs in multiprocess subprocesses. In
instances() in order to assign a unique runid to the QueryContext, and in
session instantiation in order to assign a unique hash_key to the session.
In both
