I'm not 100% sure that's what was going on (it was hard to get a debug
shell open at the moment of the error, as opposed to the assertion much
later), but switching those setattr() calls to set_committed_value()
certainly fixed it.
I admit I don't understand the session internals well enough to gr
oh, I know what you're doing, you're modifying the attributes of objects that
aren't even involved - so yes, the flush normally doesn't go finding those, and
set_committed_value() would be your workaround for now.
However, I can modify flush to do this "reset" for everything that's in
"dirty",
Indeed, session.dirty is non-empty within after_flush_postexec().
I'm working on a fix for sqlalchemy-orm-tree first before I can think about
doing a (smaller) regression test. Besides, it now occurs to me that in
some cases I might be setting attributes on objects in the session but
outside of th
On Oct 2, 2012, at 4:05 PM, Michael Bayer wrote:
>In theory it would be only .new and .dirty that might have state after the
> flush completes.
correction, ".new and .deleted" lists that might have any state.
--
You received this message because you are subscribed to the Google Groups
"
On Oct 2, 2012, at 3:49 PM, Mark Friedenbach wrote:
> Well it's hard to boil it down to a specific test case, as it affects the
> underlying assumptions that went into the design of ORM-tree. Here's an
> explanation of what I'm doing, and perhaps you can tell me if I'm (ab)using
> the API corr
I forgot to mention, this is picked up by SQLAlchemy-ORM-tree's unit tests,
if you want to see the failure:
git clone git://github.com/monetizeio/sqlalchemy-orm-tree.git
cd sqlalchemy-orm-tree && make check
On Tue, Oct 2, 2012 at 12:49 PM, Mark Friedenbach wrote:
> Well it's hard to boil it dow
Well it's hard to boil it down to a specific test case, as it affects the
underlying assumptions that went into the design of ORM-tree. Here's an
explanation of what I'm doing, and perhaps you can tell me if I'm (ab)using
the API correctly:
The meat of the code is a mapper extension whose insert,
On Oct 2, 2012, at 2:14 PM, Mark Friedenbach wrote:
> SQLAlchemy 0.7.9 seems to have broken SQLAlchemy-ORM-tree
> (http://pypi.python.org/pypi/SQLAlchemy-ORM-tree/). Specifically,
> SQLAlchemy-ORM-Tree has a dependency on flush behavior prior to the fix for
> #2566. I'm currently investigating
SQLAlchemy 0.7.9 seems to have broken SQLAlchemy-ORM-tree
(http://pypi.python.org/pypi/SQLAlchemy-ORM-tree/). Specifically,
SQLAlchemy-ORM-Tree has a dependency on flush behavior prior to the fix for
#2566. I'm currently investigating a way to detect (and ignore) the 2nd
flush.
But more genera
