Does SQLAlchemy's expire_all actually expire cached data?
<p>So, I've read a lot of conflicting reports on how sqlalchemy works. I've read that it doesn't cache queries, etc. None of it seems to match my experience.</p>

<p>I'll give an example:</p>

<pre><code>    &gt;&gt;&gt; x = Session.query(statusStorage).all()
&gt;&gt;&gt; for i in x:
...     print i.id
... 
1
... - records omitted
100000
&gt;&gt;&gt; Session.expire_all()
&gt;&gt;&gt; x = Session.query(statusStorage).all()
&gt;&gt;&gt; for i in x:
...     print i.id
... 
1
... - records omitted
100000
&gt;&gt;&gt; Session.commit()
&gt;&gt;&gt; x = Session.query(statusStorage).all()
&gt;&gt;&gt; for i in x:
...     print i.id
... 
1
... - records omitted
100001
</code></pre>

<p>So this thread is querying a MySQL database, to get all the items of a class, then printing a field. After running the first query, I run the same query in another python process, and change the ID of the last item by adding 1.</p>

<p>When I run the next request, after expire_all, it returns the same results, and the id is still unchanged. I've had this happen in code I've developed, where the search is filtered.</p>

<p>Both rollback and commit will fix the problem, both expire(object) and expire_all() fail to expire the sqlalchemy cache.</p>

<p>Am I failing to understand something implicit in sqlalchemy? Shouldn't I be able to clear the contents of the cache, without either rollback or commit? I'm running 1.0.9 on python 2.7.</p>

<p>I answered this on IRC, but the issue is simply that InnoDB's default transaction isolation level is "REPEATABLE READ", which means the second and third query are not permitted (by the database) to see your change.</p>

python sqlalchemy