Query Invalidation triggered by DDL, phase 3 This check-in allows invalidation of queries which have been prepared and are held by the EXE for execution or re-execution. It does not invalidate running queries.
When an attempt is made to (re)execute an invalidated query, a special SQLCODE, 8738, is raised and the query is sent ack to the compiler via the AQR mechanism. The check-in include a new test cases in the executor/TEST122 regression test which demonstrate the functionality.
Query Invalidation triggered by DDL, phase 1 This first check-in implements most of the framework which will be used to complete the QI DDL feature. It redefines the old security invalidation key (SQL_SIKEY) to handle DDL operations in addition to REVOKE. In a limited number of DDL operations, the object UIDs of affected Seabase objects are propagated to all nodes for use by the compiler to invalidate NATable cache entries, as well as a limited number of types of cached queries. Later this month, the framework will be complete by allowing prepared queries that have already been returned from the compiler to be invalidated. Then the next step for the framework will be support for invalidating the HTable cache. Finally an effort will be made to cover all of the necessary DDL operations and all types of cached queries.
The check-in include a new regression test (executor/TEST122) that demonstrates the cases that are covered. Specifically, a table will be dropped and recreated with the same name but different definition in one sqlci session. In another session, which has already populated NATable cache and query cache for INSERT, UPDATE, DELETE, SELECT, SELECT COUNT(*), INVOKE and SHOWDDL statements, those some types of statements will be resubmitted and correctly compiled.