id,summary,reporter,owner,description,type,status,component,version,severity,resolution,keywords,cc,stage,has_patch,needs_docs,needs_tests,needs_better_patch,easy,ui_ux 24200,Make introspection bypass statement caching on Oracle,Shai Berger,Josh Smeaton,"This comes from looking at the Oracle errors encountered in the initial fix for #24163. The Django Oracle backend currently [https://github.com/django/django/blob/master/django/db/backends/oracle/base.py#L252 uses a statement cache]. This means that if a statement is re-executed (soon enough after the previous execution), a compiled statement is fetched from the cache and performance is greatly improved. However, this causes problems with introspection during migrations; a compiled `select * from T` statement embeds in it the structure of table `T`, and if a column is dropped, then a cached `select * from T` will fail on ""ORA-01007: variable not in select list"". This is actually what happens -- [https://github.com/django/django/blob/master/django/db/backends/oracle/introspection.py#L62 get_table_description on Oracle] uses a `select * from T` query. We have run into the problem in the past, but haven't understood it properly; so we introduced a workaround of disconnecting from the database after relevant schema changes, and a database feature `connection_persists_old_columns` to control its use. But in fact, simple cache-busting (e.g. rephrasing the query as `select * from %(table)s where 0 > %(counter)d` with counter advancing each time) should solve the problem and make the disconnection, as well as the database feature, redundant. I think this fix should go also into 1.8, but definitely into master. ",Cleanup/optimization,closed,"Database layer (models, ORM)",1.8alpha1,Normal,fixed,oracle introspection,,Ready for checkin,1,0,0,0,0,0