Re: [Sqlalchemy-tickets] [sqlalchemy] #2221: evaluate "dont call backrefs during merge" behavior
Brought to you by:
zzzeek
From: sqlalchemy <mi...@zz...> - 2011-11-13 19:35:08
|
#2221: evaluate "dont call backrefs during merge" behavior ---------------------------------+------------------------------------------ Reporter: zzzeek | Owner: zzzeek Type: enhancement | Status: closed Priority: high | Milestone: 0.7.4 Component: orm | Severity: major - 1-3 hours Resolution: worksforme | Keywords: Status_field: completed/closed | ---------------------------------+------------------------------------------ Changes (by zzzeek): * status: new => closed * resolution: => worksforme * status_field: not decided upon => completed/closed Comment: OK so take a look at the tests in rec01e05c9a1c . I'm trying pretty hard to find a case where removing that check makes things faster. At the moment, I can find none. Removing the check from merge() makes these new tests perform either the same or worse - none improve. If you can figure out a test to add to that suite which illustrates less SQL being emitted, then I can start to think about this again - perhaps the reverse check can detect many-to-ones, set "passive loading" flags on so that the "set" does not emit SQL, etc., but so far I'm not seeing how that complexity and destabilization helps vs. just skipping "reverse" directions we've already done. In particular, just the "set" event on the collection side as one would expect "sets" the backref for you already, at least that's what test_pending_access_one seems to say and what my pdb's seemed to indicate. It's an intricate series of steps so my focus is perhaps only at 85% today, in the absence of an actual example of a performance increase. So closing this for now but we can reopen if better data becomes available. -- Ticket URL: <http://www.sqlalchemy.org/trac/ticket/2221#comment:12> sqlalchemy <http://www.sqlalchemy.org/> The Database Toolkit for Python |