-
Notifications
You must be signed in to change notification settings - Fork 28
Description
If I understand well, the table_listeners that put the tooling in place as well as the individual audit_table listeners that enable auditing for a single table are fired on an 'after_create' bound to a table instance.
This seems to work only when directly using the mapper constructors like create_all(), because it uses the objects as defined, whereas using alembic migrations will lose track of the objects to which the listener is bound when creating the tables, preventing it to be ever fired. (see http://stackoverflow.com/a/16907683/1877609)
It would be amazing to have some kind of interface to either (i) easily generate migrations that would basically do the job of the listeners (ii) fire the listeners' content at will.
[This issue is related to #7]
Any thought on that?