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.

Reply via email to