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.
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. 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 sqlalchemy+unsubscr...@googlegroups.com. To post to this group, send email to sqlalchemy@googlegroups.com. Visit this group at https://groups.google.com/group/sqlalchemy. For more options, visit https://groups.google.com/d/optout.
