On 02/27/2016 08:48 AM, Will Angenent wrote:
The code was just to reproduce the exact SQLA error by doing what alembic and SQLA are doing and additionally determining when the garbage collector runs. The theory is that garbage gets collected somewhere in between list(_mapper_registry) in configure_mappers and what happens in _process_dependent_arguments. The classes aren’t GC’ed since they are in use by the list statement, but by the time the callable is called, the module data has gone.
OK that specifically I can distill into a simple case which you can see here: https://bitbucket.org/zzzeek/sqlalchemy/issues/3664/un-gced-un-configured-mappers-can-be-in
I don’t consider this a bug in SQLA nor alembic individually. However, using the combination of the two has shown to be problematic. The randomness of the problem made it especially difficult to diagnose. This is probably such an edge case that it’s not worth spending any more time on. I’m happy I understand what’s going on now at least.
it's a SQLAlchemy bug, though a very edge case one.
Thanks, Will
-- You received this message because you are subscribed to the Google Groups "sqlalchemy" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To post to this group, send email to [email protected]. Visit this group at https://groups.google.com/group/sqlalchemy. For more options, visit https://groups.google.com/d/optout.
