that should have you covered i think
On Oct 9, 2014, at 1:34 PM, Tom Dalton <tom.dal...@fanduel.com> 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 <mike...@zzzcomputing.com> wrote: > > On Oct 9, 2014, at 12:16 PM, Tom Dalton <tom.dal...@fanduel.com> 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+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. > > > -- > 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. -- 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.