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, update, and delete
hooks execute SQL expressions directly to update the nested-interval tree
parameters. For efficiency I use the SQL expression layer and then manually
update the working set of ORM objects to reflect the new state.
In essence:
connection.execute(...update in sql expression language...)
for obj in session.identity_map:
...same update, as python...
(The session.identity_map is accessible to the mapper extension because it
was tucked away as a hidden attribute in the object in a session extension
before_flush handler.)
As far as I can tell, the update to the session objects is now triggering a
2nd flush, even though the purpose of the update was to refresh the objects
with their current database values. On the 2nd flush the SQL expression
updates get executed again, resulting in a corrupt database.
Any red flags in what I'm doing?
All the relevant code is in this file:
https://github.com/monetizeio/sqlalchemy-orm-tree/blob/master/sqlalchemy_tree/orm.py
On Tue, Oct 2, 2012 at 12:07 PM, Michael Bayer <[email protected]>wrote:
>
> 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 a way to detect (and ignore) the 2nd
> flush.
>
> But more generally I'm wondering what motivated #2566 in the first place?
> It has huge compatibility implications for anyone doing tricky things with
> flush and insert/update/delete events.
>
>
> #2566 was a serious issue. If dirty state remains in the session after a
> flush(), then calling commit() had the effect that *two COMMITs are
> emitted*, meaning, one COMMIT, then a brand new transaction, then another
> one, and then any dirty state left by that second commit would just be
> garbage. The commit() call flushes all remaining dirty state and it is
> essential that the session is clean after a commit occurs. 2566's fix
> should only effect when commit() is called.
>
> Feel free to send me a test case showing a valid usage that is broken by
> this change.
>
>
> --
> You received this message because you are subscribed to the Google Groups
> "sqlalchemy" group.
> To post to this group, send email to [email protected].
> To unsubscribe from this group, send email to
> [email protected].
> For more options, visit this group at
> http://groups.google.com/group/sqlalchemy?hl=en.
>
--
You received this message because you are subscribed to the Google Groups
"sqlalchemy" group.
To post to this group, send email to [email protected].
To unsubscribe from this group, send email to
[email protected].
For more options, visit this group at
http://groups.google.com/group/sqlalchemy?hl=en.
