Re: [Sqlalchemy-tickets] [sqlalchemy] #2809: Strange effect with association proxy and event listener

[sqlalchemy <mi...@zz...>]

#2809: Strange effect with association proxy and event listener
-----------------------------------+------------------------------------
      Reporter:  schlamar          |      Owner:  zzzeek
          Type:  defect            |     Status:  closed
      Priority:  medium            |  Milestone:  0.8.xx
     Component:  (none)            |   Severity:  no triage selected yet
    Resolution:  invalid           |   Keywords:
Progress State:  completed/closed  |
-----------------------------------+------------------------------------

Comment (by zzzeek):

 Replying to [comment:7 schlamar]:

 > I know that this is a constructed example, but any query to the database
 in the event handler will cause the auto flush and therefore cause this
 exception (which makes it not such a constructed case). And I know that I
 can workaround this issue by wrapping the event handler code into an with
 session.no_autoflush.

 OK well if you use most any other ORM, there either *is no flush*, you
 have to save() anytime you want INSERT or UPDATE yourself, or there are no
 attribute events. Use any of those ORMs and this problem doesn't exist -
 but neither does the feature. There is no way this particular example
 could function, because attribute events fire off before the actual change
 occurs. Only if you manually set the foreign key value to that of the
 user.id. do that if you'd like.

 > But I see this just as a workaround and not as the solution. I do not
 agree that this should be up to the user. IMO sqlalchemy should detect
 that it is in an inconsistent state where a flush would (or could) fail
 and automatically disable it until you are back in a consistent state

 SQLAlchemy would be making a significant guess here that when it goes to
 autoflush on behalf of your `job.pallets` collection that's local to your
 event handler, that it needs to be concerned about the state of what is at
 this point an entirely unrelated collection of `job.programs` that's
 external to the event handler.    If a user expects autoflush to occur, it
 would be pretty surprising and inconsistent if it turned itself off in
 certain hard-to-spot situations.   It's a lot more simple to understand
 that autoflush occurred, an integrity error happened, so therefore this
 particular event handler needs no_autoflush on it.   IMHO having a
 consistent and predictable autoflush is a lot more straightforward than an
 autoflush that makes guesses in obscure situations as to when it might not
 want to proceed, as it wouldn't be consistently effective.

--
Ticket URL: <http://www.sqlalchemy.org/trac/ticket/2809#comment:11>
sqlalchemy <http://www.sqlalchemy.org/>
The Database Toolkit for Python