TDbCache fails to recognize need to create cache table

[GoogleCodeExporter]

What steps will reproduce the problem?
1. Create a new Prado application using TDbCache
2. Run the application once
3. Drop the cache table from the database using a command-line/admin tool
4. Run the application again

What is the expected output? What do you see instead?
The program should execute normally (as it did in 3.1.4 and prior version) 
by detecting and re-creating the missing cache table. Instead it fails 
with a "TDbCommand failed to execute the SQL statement DELETE FROM 
z_cache..." fatal error. This is due to TDbCache failing to recognize that 
the cache table has been dropped in the meantime (as the quickest solution 
to clear the cache, for ex.).

What version of the product are you using? On what operating system?
Prado/3.1.5

Please provide any additional information below.
The problem lies with TDbCache.initializeCache() relying on a state 
variable set in the global (persistent) application state namespace and 
signaling the creating of the cache table, which if once set, will be 
never cleared and the existence of the cache table will never be checked 
again - not even in the case of an error when trying to access it. 

In previous Prado versions if the first operation on the cache table 
failed, the TDbCache class tried to re-create the cache table first, and 
only if this didn't succeed either, did it emit an error message. Now 
however, as stated above, the new TDbCache implementation checks only at 
the first ever run of an application using TDbCache whether the cache 
table actually exists and doesn't ever consider re-checking or trying to 
re-create it, even if an attempt to access the table fails (except when 
you change the name of the table in the application config). If, for 
whetever reason you need to recreate the underlying database of the 
application or simply just drop the cache table, your application will end 
up in a state where it can't recover from, unless you manually delete the 
global application state store "global.cache" 
under "runtime/application.xml-x.y.z" (which will also reset all other 
persistent variable for your application too).

I think the old behaviour should be brought back, meaning that if an 
attempt to access the cache table fails with an error, the table should be 
checked for existence, and if needed re-created and the original operation 
retried.

Original issue reported on code.google.com by google...@pcforum.hu on 31 May 2009 at 1:07

[GoogleCodeExporter]

Original comment by GODZilla...@gmail.com on 1 Jun 2009 at 7:47

• Changed state: Accepted

[GoogleCodeExporter]

Fixed in 3.1 branch.

Original comment by GODZilla...@gmail.com on 30 Jun 2009 at 5:20

• Changed state: Fixed