Why wouldn't you check for new, dirty deleted 'before_flush' instead of 'after_flush'. Would 'after_flush' even work?
On Thursday, October 9, 2014 at 1:34:58 PM UTC-4, Tom Dalton wrote: > > Brilliant, the after_flush event sounds like the way to go. I guess my > event handlers would be: > > after_begin: > session.info.clean = True > after_flush: > if new, dirty, deleted: > session.info.clean = False > after_commit: > session.info.clean = True > after_rollback: > session.info.clean = True > > Then in my context manager I just need to check both (current session.new > .dirty .deleted) and (my new session.info.clean attribute) to determine if > the session has been left with uncommitted changes. Does that sound like > what you'd expect? Are there any other events you can think of that I'd > need to handle/be careful of? > > Thanks a lot for your help! > > Tom > > On 9 October 2014 17:42, Michael Bayer <mik...@zzzcomputing.com > <javascript:>> wrote: > >> >> On Oct 9, 2014, at 12:16 PM, Tom Dalton <tom.d...@fanduel.com >> <javascript:>> wrote: >> >> >> Thanks for the reply. I saw the session transaction events stuff but I'm >> not sure that they help me (correct me if I'm wrong). I believe a >> transaction will exist if I run *any* query, not just one that modifies >> data. Also, the docs imply that a session will effectively always have a >> transaction when using autoflush mode. Finally, the after_begin event only >> fires once. So I'd have no way to tell the difference between the session >> state after the following 3 scenarios: >> >> 1. (implicit) begin, select, update, select, (autoflush) >> 2. (implicit) begin, select, (autoflush) >> 3. (implicit) begin, select >> >> In my use case, I want to detect the uncommitted (but flushed) changes >> and throw an error, but cases 2 and 3 are 'ok’. >> >> >> OK, so catch after_begin, as well as after_flush - inside of after_flush, >> check a boolean for .new, .dirty, .deleted, that will tell you if the flush >> actually rendered any changes (which usually it has, you can just record >> after_flush() happening at all as “changes were probably emitted”). >> >> >> >> Even disabling autoflush doesn't help, since I'd still be unable to tell >> if the (erroneous/buggy) code had done an explicit flush without a >> subsequent rollback or commit. >> >> I'm feeling a bit stuck, but I assume this information must exist in >> SQLAlchemy somewhere, since if you do: >> >> 4. (implicit) begin, select X, update X, flush, rollback >> >> then SQLAlchemy must 'know' which instance's (flushed) changes have been >> rolled back in order to change those instances' state (I think in the above >> example, it would mark X as detached?). The problem is I don't know where >> or how it's maintaining that info… >> >> >> it maintains that in session.transaction._new, >> session.transaction._dirty, session.transaction._deleted, but these are >> weak referencing (because if references to the object are lost on the >> outside, we forget about it) so aren’t guaranteed to show you that >> something definitely didn’t happen. (hence events the best way to go) >> >> >> -- >> 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+...@googlegroups.com <javascript:>. >> To post to this group, send email to sqlal...@googlegroups.com >> <javascript:>. >> Visit this group at http://groups.google.com/group/sqlalchemy. >> For more options, visit https://groups.google.com/d/optout. >> > > -- 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/d/optout.
