On Nov 5, 2010, at 8:48 PM, Yang Zhang wrote:

> Hi, we're building an application where we're distinguishing strictly
> between read-only and read-write transactions, so we'd like to (as a
> sanity measure) ensure that we're not inadvertently doing any writing
> from the read-only sections.
> 
> What's the simplest way to catch writes with sqlalchemy? Some Googling
> turned up monkey-patching the .flush() method to be a no-op that also
> logs a message, but we're interested in raising an exception if the
> flush actually has dirty data to write.


The traditional approach to this would be to connect the "read-only" session to 
an engine that's on a user with read-only permissions.     From within SQLA, I 
suppose a before_flush() extension would fit the bill here, if "new", "dirty", 
"deleted" aren't empty, raise.   If you want to be more fine grained about it 
and not trigger for attributes with no net changes, scan through "dirty" and 
see if session.is_modified(obj) returns True.


> 
> Thanks!
> --
> Yang Zhang
> http://yz.mit.edu/
> 
> -- 
> You received this message because you are subscribed to the Google Groups 
> "sqlalchemy" group.
> To post to this group, send email to sqlalch...@googlegroups.com.
> To unsubscribe from this group, send email to 
> sqlalchemy+unsubscr...@googlegroups.com.
> For more options, visit this group at 
> http://groups.google.com/group/sqlalchemy?hl=en.
> 

-- 
You received this message because you are subscribed to the Google Groups 
"sqlalchemy" group.
To post to this group, send email to sqlalch...@googlegroups.com.
To unsubscribe from this group, send email to 
sqlalchemy+unsubscr...@googlegroups.com.
For more options, visit this group at 
http://groups.google.com/group/sqlalchemy?hl=en.

Reply via email to