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 <[email protected]> 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 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.
