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). 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.
