<p dir="auto"><strong>Migrated issue, originally created by Johannes Erdfelt (<a href="https://github.com/jerdfelt">@jerdfelt</a>)</strong></p>
<p dir="auto">In some cases when code is poorly written and triggers a deadlock in the database, a confusing ResourceClosedError can be raised instead of an OperationalError which explains the deadlock.</p>
<p dir="auto">The attached script reproduces the problem. When run with the argument 'bad', it will result in this exception:</p>
<p dir="auto">ResourceClosedError: This result object does not return rows. It has been closed automatically.</p>
<p dir="auto">if run without any arguments, it results in this exception:</p>
<p dir="auto">OperationalError: (OperationalError) (1213, 'Deadlock found when trying to get lock; try restarting transaction') 'SELECT b.id AS b_id, b.value AS b_value \nFROM b \nWHERE b.id = %s \n LIMIT %s FOR UPDATE' (1, 1)</p>
<p dir="auto">The latter message is much more useful than the former, which left me scratching my head and spending a day trying to figure out what was happening.</p>
<p dir="auto">The only difference between the two is that the OperationalError case uses filter_by(id=1) whereas the ResourceClosedError case uses filter(B.value.in_(<a href="1">1</a>)). It's not clear to me yet why using the in_ filter causes a different exception to be raised.</p>
<p dir="auto">The little amount I was able to figure out before I had to move on made it look like the OperationalError was getting supressed somehow, the connection was closed and then the subsequent call to first() fails since the connection is closed (resulting in the ResourceClosedError exception).</p>
<hr>
<p dir="auto">Attachments: <a href="../wiki/imported_issue_attachments/2536/deadlock_sqlalchemy.py">deadlock_sqlalchemy.py</a></p>
<p dir="auto"><strong>Migrated issue, originally created by Anonymous</strong></p>
<p dir="auto">Hi,</p>
<p dir="auto">First, please consider I'm new to SQLAlchemy.<br>
I find the custom list classes pattern interesting, it can make a lot of use cases cleaner.<br>
However, there is an API problem: it modifies the <strong>iter</strong>_ method from dict. It can lead to subtle bugs if one doesn't pay attention, especially if someone uses the object without knowing it is managed by the SQLAlchemy mapper.</p>
<p dir="auto">What the "collection_class" option could do is see whether the custom class has a values() (or itervalues()), and use that one instead of <strong>iter</strong> it it exists. This means the user only has to add an append() method, without breaking the standard dict API (and, if he doesn't subclass dict, he just has to implement an itervalues() method instead of an <strong>iter</strong>() method).</p>