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