On Mar 8, 2009, at 3:42 PM, Alessandro Dentella wrote:
> > > Hi, > > i'm adding in sqlkit library some signals around commit, and > particularly > in post-commit phase. > > As I'd like to have the possibility to see which attributes where > modified > from within the callback I used 'after_flush' method of > SessionExtension. > > > So I have 2 questions: > > 1. Trivial tests show it behaves as I want it but how confident can > I be > that the signal is not emitted if the commit goes wrong? Is it > correct > that -as flush has already occurred- it mainly depends on what has > happened between the BEGIN statement and the COMMIT? if you want to get a view of what attrbutes were modified in a flush, after_flush() would provide a place where those attributes can be inspected before their state has been finalized. if the commit fails after the SQL is emitted, then those changes are all expired. it's unusual for the actual COMMIT to fail after the flush SQL has been emitted unless you're dealing with two-phase commit, or some kind of database failure occurred. > 2. after_flush has a flush_context argument: what can I use it for? that's the datastructure the unit of work uses to keep track of things. its probably not of much use at that stage, although you can use it to iterate through the entire flush process at a very detailed level (more detailed and implementation dependent than you'd like). I have recommended it for some people to use within before_flush() to register custom dependencies between mapped classes. --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "sqlalchemy" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [email protected] For more options, visit this group at http://groups.google.com/group/sqlalchemy?hl=en -~----------~----~----~----~------~----~------~--~---
