On Jan 15, 2014, at 7:15 PM, Ed Willis <[email protected]> wrote: > Howdy all, > > A bit of a follow up on my previous post. I'm working on a large project > with multiple sqlite databases. We're at SQLAlchemy version 0.7. On one > database, in particular, we want to identify when particular tables have > inserts/updates/deletes done on them and modify a different database when > these occur. That's all working fine now. My problem now is ensuring I get > *all* such events. What I've seen in my testing is that if I use the orm to > do the inserts/deletes/updates, my listeners are called - but if core mode is > used to modify the same tables, I don't - i.e. (and I apologize if I'm not > using the terminology correctly): > > t = MyTable(...) > session.add(t) > session.commit() > > Here I get my insert listener called. > > session.execute("insert into MyTable(...) values (...)") > session.commit() > > Here I don't. > > Now reading through the docs again more carefully, I think I see now that > that's expected. But is there a way to get SQLAlchemy to call me back > whenever inserts/deletes/updates happen on a given table, regardless of the > mode used to affect the changes? The only way I can see is to also register > for orm events - specifically execute events - and then parse the sql to see > if it affects the tables of interest. This prospect overwhelms me with > trepidation and melancholy :)
if you are sending just session.execute(), the events that trip for that are the connection-level events: http://docs.sqlalchemy.org/en/rel_0_9/core/events.html#sqlalchemy.events.ConnectionEvents.before_execute - before the SQL construct is “compiled”, if applicable http://docs.sqlalchemy.org/en/rel_0_9/core/events.html#sqlalchemy.events.ConnectionEvents.before_cursor_execute - right as we hit the cursor with a string statement. if you are sending session.execute(“insert into table”), you have to parse the SQL in order to catch that, I don’t know what the way around that would be. Of course the way DBA folks do this is to put triggers on the tables themselves. Depends on how much control you have over how this database is accessed.
signature.asc
Description: Message signed with OpenPGP using GPGMail
