On Nov 6, 2010, at 2:13 PM, Yang Zhang wrote: > Thanks, Michael. We're now doing something similar to your suggestion: > monkey-patching Session.flush() to check len(Session.dirty) == 0. This > seems to work OK. > > We can't rely on read-only DB-level users because we also use sqlite > for testing purposes, and we'd like to catch errors there too > (impractical to make our web application straddle two different Linux > users). > > SessionExtension is interesting, but it seems there's no way to pass > information to it, e.g. to let it know whether we're in a read-only > transaction or not. We could switch off between two Sessions - one > read-only and the other read-write - but we'd like to avoid having to > keep around for each web app thread multiple Sessions (and thus 2x the > open connections on the DB).
place a flag on your Session, i.e. mysession._myproject_read_only = True > > Yang > > On Fri, Nov 5, 2010 at 6:42 PM, Michael Bayer <mike...@zzzcomputing.com> > wrote: >> >> 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. >> >> > > > > -- > 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.
