Re: [sqlalchemy] Event listeners and core versus orm

[ewillis]

Thanks for the quick response. I guess I'll have to rewrite that part to define a pysqlite function‎ and then install a sqlite3 trigger that calls it. That should catch all changes regardless of how they arise.  Thanks again,       E Sent from my BlackBerry 10 smartphone on the Rogers network. From: Michael Bayer Sent: Wednesday, January 15, 2014 7:36 PM To: sqlalchemy@googlegroups.com Reply To: sqlalchemy@googlegroups.com Subject: Re: [sqlalchemy] Event listeners and core versus orm On Jan 15, 2014, at 7:15 PM, Ed Willis <ewil...@jesande.com> 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. -- 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 http://groups.google.com/group/sqlalchemy. For more options, visit https://groups.google.com/groups/opt_out.