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
<http://groups.google.com/group/sqlalchemy>.
For more options, visit https://groups.google.com/d/optout
<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
<mailto:sqlalchemy+unsubscr...@googlegroups.com>.
To post to this group, send email to sqlalchemy@googlegroups.com
<mailto:sqlalchemy@googlegroups.com>.
Visit this group at http://groups.google.com/group/sqlalchemy.
For more options, visit https://groups.google.com/d/optout.
